Description of problem: In case of Fedora 20, netatalk 3.0.6 cannot advertize by avahi when using systemd unit file. Version-Release number of selected component (if applicable): systemd-208-9.fc20.src.rpm How reproducible: On Fedora 20, # systemctl start netatalk $ avahi-browse -a -t | grep Apple (show nothing) If netatalk starts directly on shell, it is advertized. # /usr/sbin/netatalk $ avahi-browse -a -t | grep Apple + enp0s5 IPv4 pfedora20 Apple File Sharing local If "/bin/sh -c" is used in unit file, netatalk is advertized. --- /usr/lib/systemd/system/netatalk.service.orig 2013-12-17 23:46:39.952723451 +0900 +++ /usr/lib/systemd/system/netatalk.service 2013-12-17 23:47:10.113126611 +0900 @@ -9,7 +9,7 @@ [Service] Type=forking GuessMainPID=no -ExecStart=/usr/sbin/netatalk +ExecStart=/bin/sh -c /usr/sbin/netatalk PIDFile=/var/lock/netatalk ExecReload=/bin/kill -HUP $MAINPID Restart=always # systemctl start netatalk $ avahi-browse -a -t | grep Apple + enp0s5 IPv4 pfedora20 Apple File Sharing local Why is it advertized if it executes from shell? In case of Fedora 19, there is no problem. Additional info: A SRPM to which this patch is applied is here. http://netatalk.sourceforge.net/wiki/index.php/Netatalk_3.0.6_SRPMs_for_Fedora/Scientific_Linux/CentOS
This patch is already applied to netatalk 3.0.7. http://sourceforge.net/p/netatalk/code/ci/e292b73fb18c6d4bc2743301d926ece27c5f5f5d/ Netatalk 3.1.1 will also be the same. http://sourceforge.net/p/netatalk/code/ci/d3a2fc69003a058c0dceb86ade8ee814e54aa807/
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Please use this. http://netatalk.sourceforge.net/wiki/index.php/Netatalk_3.1.7_SRPM_for_Fedora_and_CentOS
ExecStart=/bin/sh -c :SBINDIR:/netatalk o_O Why do you have to escape to shell before starting the daemon?
I wrote that already. If "/bin/sh -c" is used in unit file, netatalk is advertized.
This problem shouldn't be argued now. This patch is applied to Netatalk 3.1.7 already.
Yes I noticed the wrongness in the unit file in three place so I'm aware that this patch has been applied but it does not explain why <-- you need to escape to shell ( which is not what you have written already ) to be able advertized so either the underlying problem needs to be fixed someplace in the code or the unit file lacks some environment entry Escape to the shell is a hack
Yes. This is a workaround. I don't know a reason. This patch is applied to Netatalk's original tarball already. This problem should be discussed on Netatalk's site. not here.
Hat, you have made this comment about using your source rpm on at least 5 tickets, so I think this is really the place to discuss it. Your RPM has not been through the review process of Fedora and advertising it here is not quite courteous especially if afterward you do not want to discuss about it.
I propose SRPM package for more than 7 years. However, all those were ignored. I don't want to discuss at an ignored place.
(In reply to HAT from comment #11) > I propose SRPM package for more than 7 years. > However, all those were ignored. > I don't want to discuss at an ignored place. That's sarcastic. There must be a reason that your srpm has issues. RPM built successfully doesn't mean conforming to rules in Fedora.
Why wasn't this problem pointed out 7 years ago?
Well, it is now, so maybe you are in contact with the right person now, maybe 7 years ago the maintainer was not confident or just did not know enough to engage you on this? Even then, the fact that there were no discussion until now means that you would refuse it now?
Yes! I bore a grudge against Fedora/EPEL and Debian/Ubuntu. I reform myself now. Netatalk supports all systemd-system, not Fedora/EPEL only. Therefore I don't want to argue this problem here. If not needing /bin/sh on Fedora/EPEL, please apply reverse-patch. If there is appropriate patch, I'll apply it to current netatalk tarball.
With your patch to use 'sh -c', additional variables are inserted into the environment of the process. Most likely this causes the difference in behaviour which you observe. See http://www.freedesktop.org/software/systemd/man/systemd.exec.html#Environment%20variables%20in%20spawned%20processes. I'd suggest you try to: 1. export the list of variables from netatalk running with current unit file: tr '\0' '\n' < /proc/`pidof netatalk`/environ 2. do the same for netatalk running without the shell indirection 3. compare, and either fix netatalk to not require those variables, or add them to the unit file with Environment=.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.