--- Comment #8 from Jakub Jelen <jje...@redhat.com> ---
(In reply to Darren Tucker from comment #7)
> (In reply to Jakub Jelen from comment #6)
> > Created attachment 2950 [details]
> > fixed patch
> > Never mind. Nothing from above resolves the race condition between
> > systemd reading PID file and sshd after reexec writing it, except
> > adding SD_NOTIFY code so I gave up.
> What about reading the pidfile first to see if it has the correct
> PID before rewriting it? I did something like that to work around a
> problem in pam_loginuid (LinuxPAM ticket #23, I'd link to it but
> fedorahosted.org seems to have imploded).
I don't think that would help the initial race condition, when systemd
tries to read the PID file before it is written after the daemon().
> Does systemd even need a pidfile?
>From man systemd.service:
> If this setting [Type=forking] 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.
There is also GuessMainPID= option, but from the documentation in the
same manual page I am not convinced that it is something that we would
like to use in case we can specify the PID file reliably.
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
openssh-bugs mailing list