[systemd-devel] [Netatalk-admins] Restart=always and "ExecStartPre" (netatalk)

[HAT]

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 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
>> 
>> 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 at 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