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

[HAT]

Hi,
I understood the situation to some extent.

The issue is how to read /etc/netatalk/netatalk.conf.
systemd will be able to control every process if the following terms
are satisfied.

1)
systemd itself reads netatalk.conf and startup every daemons in
environment ATALK_UNIX_CHARSET and ATALK_MAC_CHARSET.

2)
systemd itself reads netatalk.conf and startup afpd with
"-c AFPD_MAX_CLIENTS" option.

3)
systemd itself reads netatalk.conf and startup cnid_metad
with CNID_CONFIG options.

4)
If using AppleTalk, afpd must wait for starting atalkd.
If not use AppleTalk afpd must not wait for starting atalkd.

I think these are impossible.
The current implementation of netatalk 2.2.x cannot be changed.

On the other hand, your opinion is persuasive.
Many users do not use AppleTalk.
ATALK_UNIX_CHARSET and ATALK_MAC_CHARSET are not so important.
Users can write the options for afpd and cnid_metad in *.service.

I can add sample service files to contrib/ directory in tarball
if someone post more suitable service file for afpd and cnid metad only.
When AppleTalk is abolished, these file will be installed with
"--enable-redhat-systemd".

Thanks.

> the problem is that the "--enable-redhat-systemd" creates only
> a systemd-service which starts "/usr/libexec/netatalk/netatalk.sh"
> as "type=oneshot" with "RemainAfterExit"
> 
> this is all but not a systemd-service because even if you kill
> all processes "systemctl status" says "running" in green
> 
>> Is a method of using shell-script unsuitable?
> 
> yes - there should be a service for every daemon instead a workaround
> with a shell-script fire up the single-daemons out of control
> 
> they can be ordered with After/Before
> 
> from the "netatalk.sh"
>>> ATALKD_RUN=no
>>> PAPD_RUN=no
>>> TIMELORD_RUN=no
>>> A2BOOT_RUN=no
>>> ATALK_ZONE=
>>> ATALK_BGROUND=no
> 
> this would not be needed if we have 6 systemd-services which can
> all be enabled/disabled/stoped/started and would do this in a
> right order if needed - only my wish would be that "systemctl stop/start afpd.service"
> would start/stop the cnid-daemon which should also be a own service
> 
> the benefit is that this all would be run smoother and every single-service
> could use "Restart=always/onfailure" and the processes would be really
> crontrolled by systemd
> 
>> This method is inapplicable to netatalk 2.2.2.
>> Netatalk have afpd, cnid_metad, atalkd, papd, timelord and a2boot daemons
> 
> i know that my systemd-service is unacceptable upstream
> but here it is enough this time because only afpd is used
> 
>> Systemd MUST control all daemons.
> 
> but it does not!
> systemd controls exactly nothing with the "/usr/libexec/netatalk/netatalk.sh"
> and that is my problem with the current implementation of "nteatalk.service"
> 
> Am 29.09.2011 17:15, schrieb 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
> 
> -- 
> 
> 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

-- 
HAT