systemd support for various packages
Get series with b4
b4 am 20150524021840.GA13994@vostroVersions newest first
- v1 Latest0 of 38 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 38 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [Buildroot] [PATCH 00/38] systemd support for various packages
Quoted 2 lines · Cam Hutchison
Type=simple is not necessarily the best way to do this. Handling errors is done differently by systemd with Type=simple vs Type=forking.
The difference in error handling is actually why I consider non-forking services to be the only valid kind of services for anything more capable that sysv initscripts.
Quoted 9 lines
A recent blog post by Lucas Nussbaum has more details:
http://www.lucas-nussbaum.net/blog/?p=877With Type=simple, systemd considers the service started right after executing it. It will not flag errors on startup if the process exits soon after due to a config error, etc. With Type=forking, systemd will only consider the service started after the parent exits. As many daemons will check config files and command line args before forking, these errors will be detected and propagated to systemd.
Non-forking services signal initial configuration errors as well as any errors past initial configuration phase by exiting with non-zero status. Which systemd can take immediate action on, like restarting the service or marking it as failed. It's mentioned in the blog post.
Forking daemons gain marginally better *initial* error reporting by losing the ability to report errors at later stages. Detecting the state of a forked daemon (as in running or dead), or killing it, is non-trivial and generally involves time of check time of use race condition. With non-forking services, both operations are trivial and reliable.
Does knowing the fine distiction between initial and non-initial failure is worth the loss of control over the child process? I don't think so.
Reporting initial config status via parent process exit() is a specific case of startup notification, the post mentions that too. Any reliance on any kind of startup notification inherently results in time of check time of use race conditon.