Bug 1043991 - netatalk 3.0.6 cannot advertize by avahi when using systemd unit file
netatalk 3.0.6 cannot advertize by avahi when using systemd unit file
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: netatalk (Show other bugs)
20
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Christopher Meng
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-12-17 10:02 EST by HAT
Modified: 2015-06-29 20:46 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-06-29 20:46:48 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description HAT 2013-12-17 10:02:05 EST
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
Comment 2 HAT 2014-02-06 10:17:14 EST
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/
Comment 3 Fedora Admin XMLRPC Client 2014-07-02 04:47:23 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 5 Jóhann B. Guðmundsson 2015-02-26 07:12:39 EST
ExecStart=/bin/sh -c :SBINDIR:/netatalk o_O

Why do you have to escape to shell before starting the daemon?
Comment 6 HAT 2015-02-26 07:17:37 EST
I wrote that already.
If "/bin/sh -c" is used in unit file, netatalk is advertized.
Comment 7 HAT 2015-02-26 07:19:49 EST
This problem shouldn't be argued now.
This patch is applied to Netatalk 3.1.7 already.
Comment 8 Jóhann B. Guðmundsson 2015-02-26 07:29:46 EST
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
Comment 9 HAT 2015-02-26 07:41:57 EST
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.
Comment 10 Pierre-YvesChibon 2015-02-26 07:58:57 EST
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.
Comment 11 HAT 2015-02-26 08:08:41 EST
I propose SRPM package for more than 7 years.
However, all those were ignored.
I don't want to discuss at an ignored place.
Comment 12 Christopher Meng 2015-02-26 08:25:55 EST
(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.
Comment 13 HAT 2015-02-26 08:33:58 EST
Why wasn't this problem pointed out 7 years ago?
Comment 14 Pierre-YvesChibon 2015-02-26 08:40:03 EST
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?
Comment 15 HAT 2015-02-26 09:15:43 EST
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.
Comment 16 Zbigniew Jędrzejewski-Szmek 2015-02-26 09:26:36 EST
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=.
Comment 17 Fedora End Of Life 2015-05-29 06:01:07 EDT
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.
Comment 18 Fedora End Of Life 2015-06-29 20:46:48 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.