Hi, I'm a member of netatalk-admins ML. I'm subscribing to systemd-devel ML temporarily. and I'm going to unsubscribe when this problem is solved.
I added an "--enable-redhat-systemd" option to netatalk 2.2.1. This implementation is a copy of netatalk.service and netatalk.sh in netatalk-2.2.0-4.fc17.src.rpm because I don't have the knowledge of systemd. <http://koji.fedoraproject.org/koji/buildinfo?buildID=259507> This message is sent also to rpm packager. If someone offers more suitable patch, I will apply it to netatalk 2.2.2. >[root at 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 >ExecStart=/usr/sbin/afpd -P /var/run/netatalk.pid -F /etc/netatalk/afpd.conf >Restart=always >RestartSec=1 >[Install] >WantedBy=multi-user.target This method is inapplicable to netatalk 2.2.2. Netatalk have afpd, cnid_metad, atalkd, papd, timelord and a2boot daemons. Systemd MUST control all daemons. For the moment, "/etc/netatalk/netatalk.conf" must be read because the following parameters cannot be set in "/etc/netatalk/afpd.conf". ATALK_UNIX_CHARSET= ATALK_MAC_CHARSET= AFPD_MAX_CLIENTS= CNID_CONFIG= I think these parameters should be abolished in the future (netatalk 3.0?). But it is impossible in current netatalk 2.2.x. In case of netatalk 2.2.1, a shell-script "/usr/libexec/netatalk/netatalk.sh" calls netatalk.conf. Is there any method of otherwise reading netatalk.conf? IMHO, a better method is that passing options to netatalk.sh. ExecStart=/bin/sh -c "exec /usr/libexec/netatalk/netatalk.sh start" ExecStop=/bin/sh -c "exec /usr/libexec/netatalk/netatalk.sh stop" ExecRestart=/bin/sh -c "exec /usr/libexec/netatalk/netatalk.sh restart" Is a method of using shell-script unsuitable? > 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 -- HAT _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
