Page MenuHomePhabricator

systemd units are not enabled by default
Closed, ResolvedPublic

Description

systemd unit files are working, but msgcollector, sdwdate and whonixcheck are not enabled by default yet.

Seems like making packages systemd-only is non-standard and causing this issue.

* Now talking on #debian-systemd
* Topic for #debian-systemd is: user tagged bugs: http://deb.li/335K7 | wiki: http://wiki.debian.org/systemd | http://people.debian.org/~stapelberg/dashboard/ | please contribute: https://etherpad.fr/p/systemd-best-practices | SysV compat and upgrade issues: https://debian.titanpad.com/23
* Topic for #debian-systemd set by mbiebl!~quassel@g231076196.adsl.alicedsl.de at Fri Oct 24 14:54:44 2014
<adrelanos> hi! do you know any example packages, that are systemd only, that do not ship a sysvinit script?
<mbiebl> adrelanos: there are packages, which systemd units but no sysv init script
<yrro> systemd-cron perhaps?
<mbiebl> upower is such an example
<mbiebl> but those are started via different means under sysvinit
<mbiebl> i.e. directly by dbus-daemon
<mbiebl> other then that, I'm not aware of any package which does not support to be run under sysvinit
<adrelanos> okay
<mbiebl> adrelanos: why do you ask?
<adrelanos> trying to port a package to systemd. the original plan was making it systemd-only, not maintaining the sysvinit script anymore.
<adrelanos> but it seems we're trying something very unusual and should rethink this
<yrro> is there something unusual about the service? e.g., a sysvinit script that tries to manage multiple instances or something?
<yrro> i've bashed my head against too many of those for one lifetime... :)
<adrelanos> no, just a lintian warning and too little time
<mbiebl> adrelanos: keep in mind, that existing packages do typically have sysvinit scripts
<adrelanos> fear of conflicts sysinit script vs systemd also
<adrelanos> yes
<mbiebl> for new packages, it's indeed going to be interesting, who is going to maintain them
<mbiebl> i.e., rely on bug reporters / sysvinit supporters to provide them
<mbiebl> similar to how ports are handled (in theory)
<mbiebl> atm I would provide a sysvinit script along with the systemd unit 
<mbiebl> if you name them the same, systemd will pick the native unit file
<adrelanos> alright. will do.
<mbiebl> so there shouldn't be any conflict
<fsateler> adrelanos: see man 5 init-d-script , it should simplify maintainance of simple sysv services
<yrro> as long as it's a native executable ;)
<adrelanos> interesting
<adrelanos> as upstream, is it good to have 'make install' install /etc/init.d/pkg and /lib/systemd/system/pkg.service?
<algernon> second: yes, first: only if it doesn't exist (no overwrite)
<mbiebl> adrelanos: it's hard, shipping a sysv init script which works decently everywhere
<mbiebl> so I probably wouldn't bother
<mbiebl> shipping a native systemd unit is actually something systemd upstream pushes for
<mbiebl> adrelanos: please see also "man 7 daemon"
<mbiebl> section " Installing Systemd Service Files"
<ansgar> adrelanos: You should use the pkg-config path to install stuff upstream. Not everyone uses /lib/systemd/system ;)

Details

Impact
Normal

Event Timeline

Patrick updated the task description. (Show Details)May 19 2015, 5:58 PM
Patrick set Impact to Normal.
Patrick added subscribers: Patrick, nrgaway, HulaHoop.
Patrick created this task.
Patrick raised the priority of this task from to Normal.

For information, tried it out of curiosity some time ago. control-port -filter-python is working with systemd only (control-port-filter-python removed from /etc/init.d).

Good point! That will help. I'll be comparing those packages. Preferably we can keep packages systemd-only.

Created a minimal package to reproduce this issue on a plain Debian jessie system:
https://github.com/adrelanos/hellodaemon

Asked on debian systemd mailing list.
systemd unit functional, but not enabled by default issue:
https://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/2015-May/007271.html

Looks like a bug in deb-systemd-helper.

The spaces in

WantedBy = multi-user.target

are unsupported by deb-systemd-helper. It needs to be strictly without spaces.

WantedBy=multi-user.target

For reference, this is what I used for debugging.

sudo DPKG_MAINTSCRIPT_PACKAGE=hellodaemon _DEB_SYSTEMD_HELPER_DEBUG=1  perl -d:Trace /usr/bin/deb-systemd-helper enable hellodaemon.service > a 2>&1
sudo DPKG_MAINTSCRIPT_PACKAGE=control-port-filter-python _DEB_SYSTEMD_HELPER_DEBUG=1 perl -d:Trace /usr/bin/deb-systemd-helper enable control-port-filter-python.service > b 2>&1

Then compared the difff.

All these changes are available in 11.0.0.1.8-developers-only. Now testing a build.

pull request against @nrgaway/qubes-whonix,
systemd unit file remove spaces fix/workaround:
https://github.com/nrgaway/qubes-whonix/pull/3

Patrick closed this task as Resolved.May 20 2015, 7:37 PM
Patrick claimed this task.

This is fixed in 11.0.0.1.8-developers-only.

nrgaway added a comment.EditedMay 20 2015, 11:51 PM
In T316#4749, @Patrick wrote:

pull request against @nrgaway/qubes-whonix,
systemd unit file remove spaces fix/workaround:
https://github.com/nrgaway/qubes-whonix/pull/3

Merged
https://github.com/nrgaway/qubes-whonix/pull/3

That's a nasty upstream bug for deb-systemd-helper. You would have thought that would have been fixed for Jessie stable release. Do you know if there is a reported issue on it upstream?

In T316#4773, @nrgaway wrote:

That's a nasty upstream bug for deb-systemd-helper. You would have thought that would have been fixed for Jessie stable release.

Yeah. You bet. This one has cost me quite some time. But it was really worth it. Now we can do a standard conform, robust, non-error-prone, stable implementation. (No need to manually call systemd enable, which would lead to all sorts of issues [ignoring state files while reinstallation and whatnot].)

Do you know if there is a reported issue on it upstream?

Perhaps TODO? No upstream bug report yet. After reading https://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/2015-May/007273.html I don't think that's worth it. What do you think? A lintian check could be suggested, though.

I guess just not using spaces would be the way to go. I used to not use spaces, but then added them as it seems like that should be supported and works with systemd, just not the deb-systemd-helper

The man pages don't say you can or can not use extra spaces, but extra spaces do work. The issue here was, as indicated, a bug in deb-systemd-helper in which spaces are not supported even though spaces work in systemd unit files. Systemd developers should comment on this and provide clear policy in regards to spaces.

Therefore I suggest this issue be raised on systemd forums or bug tracker for their developer to comment on (not users, need a policy here) and depending on that outcome submit bug report to deb-systemd-helper.

Although it still may be worthwhile submitting the bug report for deb-systemd-helper now as well for the benefit of some other developer down the road having same issue.

Judging by the system man pages that do not use spaces and info from a systemd contributor on systemd IRC, no spaces should be used.

bug report,
deb-systemd-helper fails to enable systemd units when using 'WantedBy = ' with spaces:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786418

lintian feature request,
warn against usage of spaces, i.e. 'Type = notify' in systemd unit files:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786421