I'm using orchestrator to check if a collection of servers need to be rebooted. Here is my runbook:
The first activity will return multiple outputs with the ips of each server that I want to verify if they have a reboot pending. The next activity will invoke another runbook that only verifies if the server needs to be rebooted and that information will be added to a text file. The last activity will format some data.
(I need to check this information on two servers)
Right now the Get Hosts Name/IP runs once, the Reboot Pending activity runs twice (once for each server), and the last activity also runs twice.
I wanted to make the last activity only to run once, but I right now, no matter what I do it runs always twice.
I already tried to configure the Run Behavior Tab and Flattened the returned data. I did this in the Reboot Pending activity and the last activity. However, nothing seems to be working.
How can I make the last activity only run once after the activity before runs twice?
I used the Junction Activity and configured the Return data from
Related
I'm trying to implement a service worker in an application, but I wanted to ensure it's very resilient. I'm making sure the whole application only runs once the service worker is ready, which is generally working fine.
But when something happens during the service worker installation - like the user losing internet connection, it seems like my service worker gets stuck in the trying to install step. Only being installed after a couple of retries. I expect it to be installed as soon as the user reconnects and reloads the first time.
Is my expectation reasonable? Shouldn't the sw just resume installing in the next time the user loads the page?
Notice that this is a very rough prototype.
I want to create and host a file on a remote server and allow cytoscape to poll it every time it starts up to see if there are any changes. I'm not sure where to even start with that. Was hoping I might get some information here.
Actually, it's pretty easy. As part of your app initialization in your CyActivator, you could easily poll your remote site. The CyActivator start method gets called when Cytoscape starts up (or you app changes). I would strongly suggest that you do your poll in a separate thread since Cytoscape won't actually start until your start method returns...
-- scooter
I am using Quartz.Net 3.0.7 to manage a scheduler. In my test environment I have two instances of the scheduler running. I have a test process that runs for exactly 2 hours before ending. Quartz is configured to start the process every 10 seconds and I am using the DisallowConcurrentExecution attribute to prevent multiple instances of the task from running at the same time. 80% of the time this is working as expected. Quartz will start up the process and prevent any other instances of the task from starting until after the initial one has completed. If I stop one of the two services hosting Quart, then the other instance picks up the task at the next 10-second mark.
However, after keeping these two Quartz services running for 48 uninterrupted hours, I have discovered a couple of times where things went horribly wrong. At times host B will start up the task, even though the task is still in the middle of its 2 hour execution on host A. At one point I even found the process had started up 3 times on host B, all within a 10 minute period. So, for a two hour period, the one task had three instances running simultaneously. After all three finished, Quartz went back to the expected schedule of only having one instance running at a time.
If these overlapping tasks were happening 100% of the time, I would think there is something wrong on my end, but since it seems to happen only about 20% of the time, I am thinking it must be something in the Quartz implementation. Is this by design or is it a bug? If there is an event I can capture from Quart.Net to tell me that another instance of a task has started up, I can listen for that and stop the existing task from running. I just need to make sure that DisallowConcurrentExecution is getting obeyed and prevent a task from running multiple instances concurrently. Thanks.
Edit:
I added logic that uses context.Scheduler.GetCurrentlyExecutingJobs to look for any jobs that have the same JobDetail.Key but a different FireInstanceId when my task starts up. If I find another currently executing job, I will prevent this instance from doing anything. I am finding that in the duplicate concurrent scenario, Quartz is reporting that there are no other jobs currently executing with the same JobDetail.Key. Should that be possible? Under what case would Quartz.Net start an IJob, lose track of it as an executing job after a few minutes, but allow it to continue executing without cancelling the CancellationToken?
Edit2:
I found an instance in my logs where Quartz started a task as expected. Then, one minute later, Quartz tried to start up 9 additional instances, each with a different FireInstanceId. My custom code blocked the 9 additional instances, because it can see that the original instance was still going, by calling GetCurrentlyExecutingJobs to get a list of running jobs. I double checked and the ConcurrentExecutionDisallowed flag is true on all of the tasks at runtime, so I would expect that Quartz would prevent the duplicate instances. This sounds like a bug. Am I expected to handle this manually or should I expect Quartz to get this right?
Edit3:
I am definitely looking at two different problems. In both cases Quartz.Net is launching my IJob instance with a new FireInstanceId while there is already another FireInstanceId running for the same JobKey. In one scenario I can see that both FireInstanceIds are active by calling GetCurrentlyExecutingJobs. In the second scenario calling GetCurrentlyExecutingJobs shows that the first FireInstanceId is no longer running, even though I can see from my logs that the original instance is still running. Both of these scenarios result in multiple instances of my IJob running at the same time, which is not acceptable. It is easy enough to tackle the first scenario by calling GetCurrentlyExecutingJobs when my IJob starts, but the second scenario is harder. I will have to ping GetCurrentlyExecutingJobs on an interval and stop the task if it’s FireInstanceId has disappeared from the active list. Has anyone else really not noticed this behavior?
I found that if I set this option, that I no longer have overlapping executing jobs. I still wish that Quartz would cancel the job’s cancellation token, though, if it lost track of the executing job.
QuartzProperties.Add("quartz.jobStore.clusterCheckinInterval", "60000");
I start experimenting with Google Cloud Composer where I deploy few DAGs:
One of my DAG with an info statement indicating This DAG seems to be existing only locally. The master scheduler doesn't seem to be aware of its existence. cannot run, even manually. When I start it manually it stays on state "running" forever and never start to run the first task.
As explained in detail below the only difference between the two DAGs is that the broken one is using a custom operator.
Do you have any idea what's wrong here and how I can fix it ?
Thanks
hello2_gcp_plugins_v2 is calling the only bash and email operator is working as expected (I received the email). If I configure a scheduler_interval it's starting as expecting. Even if I set up the scheduler interval to None, it's working well when I start it manually
hello2_gcp_plugins_v5 is calling a custom operator that I already deploy in the expecting bucket. The custom operator just calls an API via the HttpHook to get data and upload it to gcs bucket via the GoogleCloudStorageHook. Whatever the scheduler interval is set up or keep to None, I always see the info statement in the UI and the DAG never start automatically. When started manually it stays in running state forever and the first task is never triggered.
I answer myself to my question as I fix it and may be useful if someone else is getting into the same trouble.
Even if it's not obvious the following information This DAG seems to be existing only locally. The master scheduler doesn't seem to be aware of its existence. was due to a buggy operator use in my DAG. In my case, one of my custom operator.
To debug it, I click on the DAG -> Graph View -> Click on my custom operator -> Task Instance Details and the stacktrace of the error in my operator was display.
I fix my operator, upload the new version in the GCS bucket and after few refresh the Web UI didn't mention the information message anymore and my DAG was running.
this can also happen if you add a new dag without stopping the scheduler and it hasn't run the refresh on the dags folder to find the new dags yet. You can change the scheduler refresh time in the airflow.cfg to make it refresh quicker.
I'm writing a simple Windows Service that sends out emails to all employees every month. My question is, how to stop itself when it's done? I'm a noobie in this field so please help me out. Really appreciated.
It will be deployed on the server to be run monthly. I did not start this thing and the code was given to me like that. It is written in VB.NET and I'm asked now to change a few things around it. I noticed that there is only 'Sub OnStart' and wondered when the service would stop? After the main sub is done, what it the status of this service? Is it stopped or just hung in there? Sorry, as I said, I am really new to this....
If you have a task that recurs monthly you may be better off writing a console app, and then using Windows Task Scheduler to set it to run monthly. A service should be used for processes that need to run for a long time or constantly, with or without a user logged on
As every other answer has noted, it sounds like this should be an executable or script that you run as a scheduled task.
However, if you are obligated for some reason to run as a Windows Service and you're working in .NET, you just have to call the Stop() method inherited from ServiceBase once your service completes its work. From the MSDN documentation for the method:
The Stop method sets the service state
to indicate a stop is pending and
calls the OnStop method. After the
application is stopped, the service
state is set to stopped. If the
application is a hosted service, the
application domain is unloaded.
There's one important caveat here: the user account under which the service is running must have permission to stop services (which is a topic for ServerFault).
Once a service's OnStart method completes, it will continue running (doing nothing) until something tells it to stop in one of the following ways:
Programatically, by calling Stop
within the service itself or from an
external process using the method
Colin Gravill describes in his
answer.
Via the command-line.
Through the windows Computer Management console's "Services" panel.
If this is a Win32 service (i.e. written in C or C++), then you simply call SetServiceStatus(SERVICE_STOPPED) and return from ServiceMain.
On the other hand, if you're just sending emails once a month, why are you using a service at all? Use the Windows Task Scheduler and run a normal application or script.
net stop [service_name] ...on the command line will do it too.
But, I agree with everyone else; it seems that Windows Task Scheduler will meet your needs better.
It might be better to write this as a scheduled task, it would certainly be easier to develop initially. Then it would naturally terminate and wouldn't be consuming resources for the rest of the month.
To answer the original question, you can get a list of the current running services in C#
services = System.ServiceProcess.ServiceController.GetServices();
Then look for the one you want and set the status to stopped
locatedService.Status == ServiceControllerStatus.Stopped
Full example on msdn
Is there a reason it has to be a Windows service? If not, then follow #Macros solution. However, if it does, then why stop the service? If you stop it, then it'll just have to be restarted when the emails need to be sent. Based on your description, it doesn't sound like it would require a lot of resources, so I'd suggest just installing it and letting it run, firing up once a month to send the emails.
here's what i did in a similar situation.
windows service runs 24/7 and processes work units. it gets work units through a database view.
table Message
ProcessingStartTime
CompletionDTE
...
the database view only pulls records marked not-complete and have a ProcessingStartTime in the past. So after the service confirms the transaction it executes a stored procedure that updates the database record. For this system, end-user upload excel files to asp.net webfrom that imports them into the database.