Am 23.11.2017 um 11:40 schrieb Gena Makhomed:
On 23.11.2017 2:30, Reindl Harald wrote:
i know that all, httpd and postfix are typically forking services and
are working fine without any PID file since 2011
# grep PIDFile /usr/lib/systemd/system/postfix.service
PIDFile=/var/spool/postfix/pid/master.pid
httpd is not Type=forking service, it is Type=notify one.
# grep Type /usr/lib/systemd/system/httpd.service
Type=notify
please don't tell me what my services are, it can be Type=notify only
when mod_systemd is compiled in but there is not compelling reason to do so
[harry@rh:~]$ rpm -q httpd
httpd-2.4.29-2.0.fc26.20171030.rh.sandybridge.x86_64
In any case, you are talking about something like workaround of the bug,
but I am asking in systemd-devel mail list about root cause of this bug,
how to fix this bug, and where bug is located - in nginx or in systemd?
in nginx which obviously creates the pid file too late
Creating pid file from grandchild process is common UNIX pattern.
Thousands of daemons are working in this way. Rewrite them all?
May be fixing systemd is far more simple than fixing all daemons?
obviously the PID file don't exist when it is expected
http://thelinuxjedi.blogspot.co.at/2014/02/why-use-double-fork-to-daemonize.html
https://www.freedesktop.org/software/systemd/man/systemd.service.html
If set to forking, it is expected that the process configured with
ExecStart= will call fork() as part of its start-up. The parent process
is expected to exit when start-up is complete and all communication
channels are set up. The child continues to run as the main daemon
process. This is the behavior of traditional UNIX daemons. If this
setting is used, it is recommended to also use the PIDFile= option, so
that systemd can identify the main process of the daemon. systemd will
proceed with starting follow-up units as soon as the parent process exits.
_______________________________________________
systemd-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
