The definition given in the man for systemd unit is a bit sparse:
https://www.freedesktop.org/software/systemd/man/systemd.unit.html
"If a unit foo.service contains a setting Before=bar.service and both units are being started, bar.service's start-up is delayed until foo.service is started up."
I couldn't find any conclusive explanation on what 'started up' means. Is this just the call from systemd to the service to start up. Or does systemd wait for the service to enter a specific state after which it is considered to be up? Can I read details on how this works anywhere?
Before being active, service is in activating mode. systemd waits for the service to fully enter in active mode. Only after that it calls dependent service to start.
Related
I created a script which is supposed to run as a daemon, controlled by systemd. I came across ancient questions like What is the reason for performing a double fork when creating a daemon? and ancient documentation, which suggests that daemons should fork to detach from a terminal.
But in 2020, using systemd, all of this seems obsolete to me. As far as I understand (with support from https://jdebp.eu/FGA/unix-daemon-design-mistakes-to-avoid.html), there is no need to detach from any terminal, no need to avoid zombie processes etc. The whole forking-and-exiting only makes sense to me if I want to start the daemon manually from a terminal and not with systemd.
Am I right or is there still any benefit from forking inside a daemon and exiting the parent?
You are correct. The forking is now 100% handled by the systemd environment so there is really no need to do anything in that arena. It even saves the PID which you can access in the StopExec=... as $MAINPID:
StopExec=/bin/kill "$MAINPID"
If your daemon has a forking capability, you can use it with the forking type:
[Service]
type=forking
But if you don't have any forking mechanism in your daemon, don't implement it. It's useless.
Note that from the command line, you can always use the & to start it in the background. That's explicit. People can clearly understand how that works.
Another point, many people would use a PID file to save that identifier and use it to kill the process on a stop. That PID file was also useful to prevent the administrator from starting a second instance of the same service. Again, systemd takes care of that. You can have at most one instance of any service.
I have WMware installed. But I don't use it often so I open Services, stop all WMware services and set start type for them as manual. So after restart windows all this services are stopped. When I need WMvare I just go to services and start them. This approach worked fine untill I upgraded to Windows 10. At Win 10 after restarting system MWware services works if they was working before restart. If I stop services before restart they will not work after restart. So I think Win10 somehow remember last service state and restore it after restart. This is not about WMware services only. Other services behaves the same way. So my question is there some way disable remembering last service state after restart at Windows 10?
Startup Type" for Service
Automatic - With a service in this state, it will start at boot time. Some services, when no longer required, will also automatically stop when not needed. If you find you do not need a service, place it into Manual or Disabled.
Automatic (Delayed Start) - With a service in this state, it will start just after boot time. Some services, when no longer required, will also automatically stop when not needed. If you find you do not need a service, place it into Manual or Disabled.
Automatic (Delayed Start, Trigger Start) - With a service in this state, it will start just after boot when specifically called.
Manual (Trigger Start) - This is a version of Manual mode that allows Windows to start a service when specifically called and Microsoft’s answer to “too many services running all the time”.
Manual - Manual mode allows Windows to start a service when needed. However, very few services will start up when required in Manual mode. If you find you need a service, place it into Automatic.
Disabled - This setting will stop a service from starting, even if needed. Errors in the Event Viewer will show up complaining of that fact. Some services, while Disabled, will constantly complain. However, this situation is taken care of if placed in Manual. The service descriptions identifies those that should be in Manual vice Disabled.
I have an executable that I would like to set to run as a service. Using the sc.exe tool provided by windows (see KB article here: http://support.microsoft.com/kb/251192), I successfully "registered" the service. However, when I go to the Service Management Console (Start->Run->services.msc) and start the service, I get the following error:
Error 1053: The service did not respond to the start or control request in a timely fashion.
After reading around my initial impression is that service executables have to conform to an API, and that among the required functions/methods a service has to respond to are a start/stop/restart command. However, this seems to defeat the whole point of the sc.exe tool which is advertised with the ability to turn any executable into a service.
Can anyone shed some light on this for me?
This is the code you are looking for:
sc create SERVICENAME binPath= "cmd /c c:\programlocation\program.exe"
It will not rid you of error 1053, but at least this will apply to the console (CMD) who already did the job of running the app in the background (check task manager to confirm).
Take a look at Topshelf-project which turns many arbitrary executables into services.
When you reference Topshelf, you can run your exe from a command-line, or install it into Windows Services with:
your.exe install
Even with topshelf registered, you would still want to have a logging facility -- such as log4net -- to monitor bootstrapping activities that could prevent it from launching in a timely fashion.
One very likely cause of this behavior is the application that is started is displaying a request for interaction with the end user (messagebox, input prompt, licensing dialog, etc). We have run into this more than once. This usually happens with applications that aren't designed to run as services. You could try running the service as Local System and check the Allow service to interact with desktop checkbox.
The other possibility is that the user the service is configured to run as doesn't have access to resources (disks, databases, etc). If the process works correctly interactively, then try changing the service's user credentials to your user and see if that gets you any further.
Update
Apologies, I assumed the question was regarding srvany which is the application you are looking for.
I'm very interested in the answer to another question regarding watchdog timers for Windows services (see here). That answer stated:
I have also used an internal watchdog system running in another thread. That thread looks at the main thread for activity like log output or a toggling event. If the activity is not seen then the service is considered hung and I shutdown the service.
In this case you can configure windows to auto-restart a stopped service and that might clear the problem (as long as it's not an internal logic bug).
Also services I work with have text logs that are written to a log. In addition for services that are about to "sleep for a bit", I log the time for the next wake up. I use MTAIL to watch a log for output."
Could anyone give some sample code how to use an internal watchdog running in another thread, since I currently have a task to develop a windows service which will be able to self restart in case it failed, hung up, etc.
I really appreciate your help.
I'm not a big fan of running a watchdog as a thread in the process you're watching. That means if the whole process hangs for some reason, the watchdog won't work.
Watchdogs are an idea lifted from the hardware world and they had it right. Use an external circuit as simple as possible (so it can be provably correct). Typical watchdogs simply ran an timer and, if the process hadn't done something before the timer expired (like access a memory location the watchdog was watching), the whole thing was reset. When the watchdog was "kicked", it would restart the timer.
The act of the process kicking the watchdog protected that process from summary termination.
My advice would be to write a very simple stand-alone program which just monitored an event (such as file update time being modified). If that event didn't occur within the required time, kill the process being watched (and let Windows restart it).
Then have your watched program periodically rewrite that file.
Other approaches you might want to consider besides regularly modifying the lastwritetime of a file would be to create a proper performance counter or even a WMI object. We do the later in our build infrastructure, the 'trick' is to find a meaningful work unit in the service being monitored and pulse your 'heartbeat' each time a unit is finished.
The advantage of WMI or Perf Counters over a the file approach is that you then become visible to a whole bunch of professional MIS / management tools. This can add a lot of value.
You can configure from service properties to self restart in case of failure
Services -> right-click your service -> Properties -> First failure : restart the service -> Second failure : restart the service -> Subsequent failure : restart
I want to schedule a restart of my custom services
automatically using a batch file with net stop, net start.
When net stop runs does it abort anything that is being done
immediately?
Just wondering what will happen if in the middle of processing?
Malcolm
It will call into your code asynchronously and it will be up to you to deal with it. You could enact a clean or abort as you see fit.
It really depends on how the service is implemented. "net stop" essentially calls into the service and says "would you kindly stop". Most services will comply with this command and stop in a timely fashion. However there are the bad services which do not comply and refuse to stop. In this case, net stop will take no further action.
It really depends on the service. I suspect most will try to get into a good state before stopping. It isn't a kill.
A service registers to receive events (via RegisterServiceCtrlHandler). When you do a net stop the registered callback will receive a callback with the SERVICE_CONTROL_STOP operation. How the service responds to that callback is up to the service implementation. It would make sense for the service to do regular application shutdown processing.
Like the others said, when you call net stop, it will invoke the OnStop in the Windows Service. If the OnStop does not kill all the threads in the app, or doesn't shut everything down properly, your service might not stop. (I've seen this happen in one of our WCF services: we didn't close the ServiceHost in OnStop, and therefore, the app would not stop at our command - we'd have to kill the process by hand.)
One common pattern I've seen is to try calling stop on the service, and if it doesn't die within a timeout (10 seconds), kill the process by force. As an alternative to batch files, PowerShell has some pretty good support for dealing with services.