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@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 > > -- > > 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 _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
