thank you for your reply first i tried two services (netatalk.service + netatalk-cnid.service) but for whatever reason /usr/sbin/cnid_metad will be started with a correct zero-return-value but the process is closed, tried preforking/simple
the other "problem" is that i want take away complexity for start/restart at the user/admin-level there should be only used "netatalk.service" this works fine with Requires= for the first start, but not when stop netatalk.service in a way that netatalk-cnid.service is stopped also background-informations: afpd: the apple fileserver cnid_meta: a shared service for the AppleDB upstream has included a systemd option in netatalk-2.2.1-p1 but the created systemd-service does not satisfy me because it is a shellscript reading/defining some shell-vars and starting both processes as "oneshot" with "RemainAfter" wthat means that "Restart" is generally not possible and even if you kill both processes "systemctl status" says "running", so this is a wrapper which is faking a systend-service without any benefit a copy of my reply goes ot the netatalk-mailing-list maybe they could optimize this upstream and provide the service file as textfiel in the tarball instead generate it with the configure-options to make custom builds easier however, the fileserver is an internal service but i would love to use the restart-options and install a cron-script parsing /var/log/messages for systemd-restart-events to send mail-notifies Retart=always is one of the few current available improvements of systemd over the old sysvinit to make even rock solid services more stable by restart them at the few crashes instead fireup a alarm-mail thanks! Am 28.09.2011 22:48, schrieb Michal Schmidt: > On Wed, 28 Sep 2011 17:49:54 +0200 Reindl Harald wrote: >> why does systemd not restart a killed service if the >> "ExecStartPre"-process is still running, see below - at my opinion >> after "killall afpd" the service should be restarted and in a perfect >> case even if "ExecStartPre"-process dies >> >> systemd-26-10.fc15.x86_64 > > I see at least three issues here. See below. > >> [root@testserver:~]$ cat /lib/systemd/system/netatalk.service >> [Unit] >> Description=Apple-File-Server >> After=syslog.target network.target avahi-daemon.service >> [Service] >> Type=forking >> PIDFile=/var/run/netatalk.pid >> ExecStartPre=/usr/sbin/cnid_metad -l log_note > > issue #1: > ExecStartPre is not supposed to fork off daemons. A future version of > systemd might even enforce this rule. The service should be split into > two. > >> ... >> [root@testserver:~]$ systemctl status netatalk.service >> netatalk.service - Apple-File-Server >> Loaded: loaded (/lib/systemd/system/netatalk.service) >> Active: active (running) since Wed, 28 Sep 2011 17:45:55 >> ... >> Main PID: 1812 (code=exited, status=0/SUCCESS) > > issue #2: > This Main PID looks like stale information from a previous run of the > service. This is a minor bug in systemd that it does not reset it. > > There are two reasons why systemd failed to detect the new main PID: > - issue #3: afpd has a racy daemonization sequence. It writes its PID > file too late. My recently proposed patch "service: delayed main PID > guessing" should be able to workaround it. > - Given that systemd could not read the information from the PID file, > it tried to guess the main PID, but it also failed, because there > are two top-level processes in the cgroup: > >> CGroup: name=systemd:/system/netatalk.service >> ├ 1999 /usr/sbin/cnid_metad -l log_note >> └ 2002 /usr/sbin/afpd -P /var/run/netatalk.pid -F /etc/netatalk/afpd.conf > > systemd could tell which one of them is the main PID. > > When the main PID is not known, the only way to detect the death of the > service is to watch for the cgroup getting empty. > > Michal > _______________________________________________ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Mit besten Grüßen, Reindl Harald the lounge interactive design GmbH A-1060 Vienna, Hofmühlgasse 17 CTO / software-development / cms-solutions p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40 icq: 154546673, http://www.thelounge.net/ http://www.thelounge.net/signature.asc.what.htm
signature.asc
Description: OpenPGP digital signature
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel