Am 30.12.2016 um 08:26 schrieb Konstantin Khomoutov: > Package: mpd > Version: 0.19.21-1 > Severity: important > > Hi! > > After upgrading an i686 machine running mpd from Jessie to Stretch, > I noticed mpd won't start -- exiting with return code 1 early at > startup: > > | Dec 30 10:16:52 jukebox systemd[1]: [/lib/systemd/system/mpd.service:25] > Unknown lvalue '
' in section 'Service' > | Dec 30 10:16:54 jukebox systemd[1]: Started Music Player Daemon. > | Dec 30 10:16:55 jukebox mpd[4936]: config_file: loading file /etc/mpd.conf > | Dec 30 10:16:55 jukebox systemd[1]: mpd.service: Main process exited, > code=exited, status=1/FAILURE > | Dec 30 10:16:55 jukebox systemd[1]: mpd.service: Unit entered failed state. > | Dec 30 10:16:55 jukebox systemd[1]: mpd.service: Failed with result > 'exit-code'. > > Running > > /usr/bin/mpd --no-daemon -v /etc/mpd.conf > > by hand as root worked OK, so I've changed the ExecStart parameted in > the Systemd unit to > > /usr/bin/strace -o /tmp/mpd.log -f /usr/bin/mpd --no-daemon -v $MPDCONF > > commented out all the system protection options, then started to > uncomment them one by one -- attempting to start the unit each time > (with proper invocations of `systemctl daemon-reload` in between). > > Finally this spotted the problem which is the > > RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX AF_NETLINK > > option. With it being commented out, mpd starts OK. > > Analyzing the strace output for relevant problems brought up several > attempts at opening sockets -- of types AF_UNIX and AF_INET. > Several of such failed attempts apparently get ignored by mpd, but the > last one actually makes it exit (silently for whatever reason) but with > the result code of 1. > The last lines of the strace's output are: > > | 4938 socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = -1 EPROTONOSUPPORT > (Protocol not supported) > | 4938 exit_group(1) = ? > | 4938 +++ exited with 1 +++ > > and the result of grepping it for EPROTONOSUPPORT is: > > | 4743 socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = -1 > EPROTONOSUPPORT (Protocol not supported) > | 4743 socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = -1 > EPROTONOSUPPORT (Protocol not supported) > | 4743 socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = -1 > EPROTONOSUPPORT (Protocol not supported) > | 4743 socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = -1 > EPROTONOSUPPORT (Protocol not supported) > | 4743 socket(AF_INET, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = > -1 EPROTONOSUPPORT (Protocol not supported) > | 4743 socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = -1 EPROTONOSUPPORT > (Protocol not supported) > > > As to the essense of this but, it rather appears to affect Systemd v232 > (as shipped by Stretch) specifically on i686 systems [1]. > > That bug's thread mentions [2], so I've added the unstable repository > and attempted to install systemd from there via > > apt install -t unstable systemd > > but it told me the package I have installed is already the newest > version, and its changelog has the following snippet: > > ----------------8<---------------- > systemd (232-2) unstable; urgency=medium > > * Drop RestrictAddressFamilies from service files. > RestrictAddressFamilies= is broken on 32bit architectures and causes > various services to fail with a timeout, including > systemd-udevd.service. > While this might actually be a libseccomp issue, remove this option for > now until a proper solution is found. (Closes: #843160) > > -- Michael Biebl <[email protected]> Sat, 05 Nov 2016 22:43:27 +0100 > ----------------8<---------------- > > So it appears you'd better comment that option as well for now of ship > a dedicated unit files specifically for i686 systems if this is > possible. > > OTOH, upstream appears to have some developments on [1], so maybe asking > systemd maintainers on whether it's possible to integrate some upstream > fix for this seccomp issue is worthwhile. Your analysis seems to be correct. Until systemd is fixed, you should not use RestrictAddressFamilies= I'm not sure whether we will get v233 for stretch and if backporting those upstream fixes for v232 is feasible. As for RestrictNamespaces=, I'm pretty sure we won't backport that feature for v232, so I'd suggest removing that as well for now until v233 is actually available. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pkg-systemd-maintainers mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
