systemd support for various packages
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest21 of 38 patches 0 repliesNew
21 of 38 patches are in this archive. The cover letter announces 38.
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 2/38 | chrony: systemd support | +0 | 0 replies | |
| 3/38 | dcron: systemd support | +0 | 0 replies | |
| 7/38 | exim: systemd support | +0 | 0 replies | |
| 9/38 | inadyn: systemd support | +0 | 0 replies | |
| 10/38 | inadyn: start in background mode | +0 | 0 replies | |
| 11/38 | input-event-daemon: systemd support | +0 | 0 replies | |
| 14/38 | mongoose: systemd support | +0 | 0 replies | |
| 17/38 | netplug: systemd support | +0 | 0 replies | |
| 19/38 | olsr: systemd support | +0 | 0 replies | |
| 20/38 | proftpd: systemd support | +0 | 0 replies | |
| 21/38 | ptpd: systemd support | +0 | 0 replies | |
| 23/38 | pulseaudio: systemd support | +0 | 0 replies | |
| 25/38 | rpi-userland: systemd support | +0 | 0 replies | |
| 27/38 | ti-gfx: systemd support | +0 | 0 replies | |
| 28/38 | squid: systemd support | +0 | 0 replies | |
| 30/38 | tinyhttpd: systemd support | +0 | 0 replies | |
| 32/38 | upmpdcli: systemd support | +0 | 0 replies | |
| 34/38 | triggerhappy: systemd support | +0 | 0 replies | |
| 35/38 | supervisor: systemd support | +0 | 0 replies | |
| 37/38 | samba4: install systemd files | +0 | 0 replies | |
| 38/38 | mysql: systemd support | +0 | 0 replies |
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
Alex, Cam,
Could you reach to an agreement on this point? I am not a systemd expert, and from a quick reading of Lucas Nussbaum blog post, there does not seem to be a perfect solution (besides changing the service source code itself to make it more systemd aware).
It would be great to be able to move forward with this patch series.
Thanks for your help,
Thomas
Quoted 41 lines · Alex Suykov
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.
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com