Hi Lukas, > I tried to look into systemd documentation and I could not see > anything in documentation which would say that it is a reliable > way to use a pid file. (It might change in future if it is not documented) > > man systemd.service says > 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. > //snip > PIDFile= > Takes an absolute file name pointing to the PID file of this > daemon. Use of this option is recommended for services where Type= > is set to forking. systemd will read the PID of the main process of > the daemon after start-up of the service. systemd will not write to > the file configured here, although it will remove the file after > the service has shut down if it still exists. > > It might help for upstart but for systemd it might be better to use > "Type=notify" instead of "Type=forking". >
I haven't tried using "Type=notify", but I don't think it would make a difference if we can't hold the notification signal until the responders are running. > Is the bug reproducible only with upstart or also with systemd? > For systemd only I would prefer "Type=notify" > I've been able to reproduce this bug in both upstart and systemd, but the numbers differ significantly (~40% of the runs with upstart, ~1% or less with systemd). Kind regards, Victor _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
