Bugzilla – Bug 659357
systemd: we need to call 'systemctl enable *.service' at rpm install time of packages
Last modified: 2011-09-29 09:57:20 UTC
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_5; en-US) AppleWebKit/534.15 (KHTML, like Gecko) Chrome/10.0.611.0 Safari/534.15 Installed systemd and systemd-sysvinit. Upon startup everything seems to be fine but avahi-daemon is not started. Reproducible: Always Steps to Reproduce: 1. Installed systemd and systemd-sysvinit 2. Restart 3. Notice that you can't browser zeroconf networks because avahi-daemon is not started. Actual Results: avahi-daemon is not started. Expected Results: avahi-daemon runs on startup.
Please run: /bin/systemctl enable avahi-daemon.service it will enable systemd which is not done automatically from the spec file. Vincent, for now, care to add: %post if [ "$1" -eq 1 ]; then /bin/systemctl enable avahi-daemon.service >/dev/null 2>&1 || : fi to the spec file? That way, avahi will get enabled on *first install*. How to handle enable it on package *updates* on SUSE is still not decided. Fedora uses chkconfig and %triggerun -- we need to come up with something here.
Kay: that's typically the kind of scriptlets where I'd love to get a macro so that, if later on, we choose to handle it differently in %post, we don't have to fix all packages. Does it make sense to define a macro for this and ship it somewhere? Also, do we want to handle the case where systemd is installed after avahi?
Yeah, that's why I kept the bug. We need to sort that out. A macro sounds nice. But ... I have no real idea how to do the "enable systemd service "only-when-it-is-enabled-in-sysv" -- and do all that only once when the systemd service files are introduced, and never on later updates. We probably don't really have these package version checks available for the triggers like Fedora, but I don't know ...
alsa-utils.spec has code like this: %if %use_systemd ln -s alsa-restore.service $RPM_BUILD_ROOT/lib/systemd/system/alsasound.service %endif Does this help?
(In reply to comment #4) > alsa-utils.spec has code like this: > > %if %use_systemd > ln -s alsa-restore.service > $RPM_BUILD_ROOT/lib/systemd/system/alsasound.service > %endif This just short-cuts the old init script, which should never be executed on systemd boots. It does not enable anything. Unlike avahi, the installed alsa services do not have that install/udate problem, they are always pulled-in from /lib/systemd/. They are not configurable, and can not be turned off -- only by linking them to /dev/null in /etc/systemd/.
It's currently: cron, avahi, acpid which install systemd service files, and can be enabled/disabled. At package install time, we can do: %post if [ "$1" -eq 1 ]; then /bin/systemctl enable foo.service >/dev/null 2>&1 || : fi There is still no solution how to do this on package upgrade when the systemd service file is introduced, but not on any later upgrade.
*** Bug 660493 has been marked as a duplicate of this bug. ***
*** Bug 681074 has been marked as a duplicate of this bug. ***
*** Bug 704800 has been marked as a duplicate of this bug. ***
I'm implemented a solution to only enable systemd service first time a .service is introduced in a package (ie migrating from sysvinit to unit file), with three macros : %service_migrate_to_systemd_pre / %service_migrate_to_systemd_post / %service_migrate_to_systemd_postun I got a request to try to merge those macros into %service_add / %service_del_preun / %service_del_postun
fixed, we now ship %service_add_pre/post %service_del_preun/postun which calls systemctl preset to enable services listed in systemd preset directory (and packaged in systemd-presets-branding-openSUSE).