http://bugzilla.opensuse.org/show_bug.cgi?id=904215 Johannes Meixner changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |thomas.blume@suse.com Flags| |needinfo?(thomas.blume@suse | |.com) --- Comment #1 from Johannes Meixner --- In openSUSE 13.1 the cups RPM contained /usr/lib/systemd/system/cups.path /usr/lib/systemd/system/cups.service /usr/lib/systemd/system/cups.socket In openSUSE 13.2 the cups RPM contains /usr/lib/systemd/system/cups.service /usr/share/doc/packages/cups/systemd/cups.path /usr/share/doc/packages/cups/systemd/cups.socket Reasoning: See bug#857372 for the full sad story - but at least I learned how to deal with newest fancy features in the future ;-) cf. https://bugzilla.opensuse.org/show_bug.cgi?id=857372#c133 and https://bugzilla.opensuse.org/show_bug.cgi?id=857372#c140 and https://bugzilla.opensuse.org/show_bug.cgi?id=857372#c148 Thomas Blume, when after RPM package upgrade a systemd unit file does no longer exist (because it is no longer provided by the new RPM), what is the right way how to tell that to systemd? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=904215 Johannes Meixner changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dominian@slackadelic.com Flags| |needinfo?(dominian@slackade | |lic.com) --- Comment #3 from Johannes Meixner --- Matt Hayes, is it o.k. after you did run "systemctl daemon-reload"? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=904215 --- Comment #6 from Johannes Meixner --- See /usr/share/doc/packages/rpm/manual/triggers ---------------------------------------------------------------------------- For reference, here's the order in which scripts are executed on a single package upgrade: all-%pretrans ... any-%triggerprein (%triggerprein from other packages set off by new install) new-%triggerprein new-%pre for new version of package being installed ... (all new files are installed) new-%post for new version of package being installed any-%triggerin (%triggerin from other packages set off by new install) new-%triggerin old-%triggerun any-%triggerun (%triggerun from other packages set off by old uninstall) old-%preun for old version of package being removed ... (all old files are removed) old-%postun for old version of package being removed old-%triggerpostun any-%triggerpostun (%triggerpostun from other packages set off by old un install) ... all-%posttrans ---------------------------------------------------------------------------- This means while "systemctl daemon-reload" is run in new-%post the old files /usr/lib/systemd/system/cups.path /usr/lib/systemd/system/cups.socket still exist. Only old-%postun (i.e. the postuninstall scriptlet in the old cups RPM) is run after the old files have been actually removed. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=904215 --- Comment #13 from Matt Hayes --- Well, the issue still persists. System just notified me again of the same error: 2014-11-06T12:45:01.233911-05:00 destiny systemd[1]: Cannot add dependency job for unit cups.socket, ignoring: Unit cups.socket failed to load: No such file or directory. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=904215 Johannes Meixner changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Other |Basesystem Found By|Community User |Development Assignee|bnc-team-screening@forge.pr |systemd-maintainers@suse.de |ovo.novell.com | Summary|"systemctl daemon-reload" |"systemctl daemon-reload" |does not clean up broken |should clean up broken |symlinks to unit files |symlinks to unit files -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=904215 --- Comment #16 from Johannes Meixner --- FYI: Regarding the general problem that currently all RPM scriptlets of the new package are run before the old package stuff is done so that the new package cannot fix or clean up stuff after the old package was removed I submitted bug#904351 -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=904215 --- Comment #20 from Johannes Meixner --- In the new RPM only "new-%posttrans" runs after all old files are removed but as far as I know %posttrans scriptlets are basically forbidden in OBS because they cause issues (I don't know the details). If I understand it correctly systemd must keep its symlinks even if they are broken because the brokenness could be a temporary error (e.g. because of whatever temporary error elsewhere). In the end it seems it cannot be solved by any automatism so that really the admin must explicitly tell the system via a manual command what he actually wants. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=904215 Johannes Meixner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |IN_PROGRESS Component|Basesystem |Printing QA Contact|qa-bugs@suse.de |jsmeix@suse.com -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=904215 Johannes Meixner changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |systemd-maintainers@suse.de Flags| |needinfo?(systemd-maintaine | |rs@suse.de) --- Comment #24 from Johannes Meixner --- I like to use the following %posttrans scriptlet in cups.spec: ----------------------------------------------------------------------------- %posttrans %if 0%{?have_systemd} # The following is a generic way to refresh and/or clean up systemd units. # A systemd unit may need a refresh after updating a package # when the new package had installed a changed systemd unit file # for an enabled systemd unit. # A systemd unit may become obsolete by updating a package. # A systemd unit is considered to have become obsolete # when the systemd symlink # /etc/systemd/system/.../unit_name -> /path/to/unit_file # is broken. for u in cups.service cups.socket cups.path do if systemctl --quiet is-enabled $u 2>/dev/null then # Refresh valid systemd units: systemctl --quiet reenable $u || : else # Clean up obsoleted systemd units: systemctl --quiet stop $u 2>/dev/null || : systemctl --quiet disable $u || : fi done %endif ----------------------------------------------------------------------------- Is this a reasonable way how to clean up systemd units? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=904215 --- Comment #28 from Johannes Meixner --- Thomas Blume, did you try out "systemctl list-dependencies"? For me it does not work to determine if a unit would be started during a normal system boot: --------------------------------------------------------------------------- # systemctl status iscsid.socket iscsid.socket Loaded: not-found (Reason: No such file or directory) ... # file /etc/systemd/system/sockets.target.wants/iscsid.socket /etc/systemd/system/sockets.target.wants/iscsid.socket: broken symbolic link to `/usr/lib/systemd/system/iscsid.socket' # systemctl list-dependencies default.target ... * `-multi-user.target ... * |-basic.target ... * | |-sockets.target ... * | | |-iscsid.socket # systemctl list-dependencies iscsid.socket && echo ok iscsid.socket ok --------------------------------------------------------------------------- But the iscsid.socket cannot be started during normal boot because its systemd symlink is broken. When directories where symlinks for system units can appear are really those 3 fixed directories then the following seems to work: --------------------------------------------------------------------------- # for u in iscsi ; \ do for l in $( find /etc/systemd/system /usr/lib/systemd/system \ /run/systemd/system -type l -name "$u*" ) ; \ do test -e $l && echo ok $l || echo broken $l ; \ done ; \ done broken /etc/systemd/system/sockets.target.wants/iscsid.socket ok /etc/systemd/system/remote-fs.target.wants/iscsi.service # file /etc/systemd/system/sockets.target.wants/iscsid.socket /etc/systemd/system/sockets.target.wants/iscsid.socket: broken symbolic link to `/usr/lib/systemd/system/iscsid.socket' # file /etc/systemd/system/remote-fs.target.wants/iscsi.service /etc/systemd/system/remote-fs.target.wants/iscsi.service: symbolic link to `/usr/lib/systemd/system/iscsi.service' --------------------------------------------------------------------------- Only FYI: To only let 'find' output broken symlinks one can use the '-L' option together with '-type l': --------------------------------------------------------------------------- # for u in iscsi ; \ do find -L /etc/systemd/system /usr/lib/systemd/system \ /run/systemd/system -type l -name "$u*" ; \ done /etc/systemd/system/sockets.target.wants/iscsid.socket --------------------------------------------------------------------------- I have to carefully think about if I really want to implement it via find when there is no generic native systemd way how one could implement it. I have the dim feeling it will cause weird subsequent issues in the future. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=904215 --- Comment #31 from Johannes Meixner --- One cannot use the return value of "systemctl status" to check if a unit is running, see bug#901796 and bug#880103 Perhaps using the generic native systemd way via "systemctl" is in the end even more complicated than using low-level tools like 'find' to inspect systemd's files directly... -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=904215 --- Comment #34 from Johannes Meixner --- I did some experiments on an openSUSE 13.1 system and my result is that systemctl --force reenable seems to do "the right thing". A short summary of my experiments: ---------------------------------------------------------------------------- # systemctl list-unit-files | grep cups cups.path enabled cups.service enabled cupsd.service enabled cups.socket enabled # find /etc/systemd/system/ -ls | grep -o '/etc/.*cups' /etc/systemd/system/multi-user.target.wants/cups.path -> /usr/lib/systemd/system/cups.path /etc/systemd/system/sockets.target.wants/cups.socket -> /usr/lib/systemd/system/cups.socket /etc/systemd/system/cupsd.service -> /usr/lib/systemd/system/cups.service /etc/systemd/system/printer.target.wants/cups.service -> /usr/lib/systemd/system/cups.service # mv /usr/lib/systemd/system/cups.path /usr/lib/systemd/system/cups.path.away # ln -sf /usr/lib/systemd/system/cups.socket.no /etc/systemd/system/sockets.target.wants/cups.socket # for u in cups.service cups.socket cups.path ; \ do echo $u: ; systemctl --force reenable $u ; done cups.service: Failed to issue method call: No such file or directory cups.socket: rm '/etc/systemd/system/sockets.target.wants/cups.socket' ln -s '/usr/lib/systemd/system/cups.socket' '/etc/systemd/system/sockets.target.wants/cups.socket' cups.path: Failed to issue method call: No such file or directory # find /etc/systemd/system/ -ls | grep -o '/etc/.*cups.*' /etc/systemd/system/cupsd.service -> /usr/lib/systemd/system/cups.service /etc/systemd/system/printer.target.wants/cups.service -> /usr/lib/systemd/system/cups.service /etc/systemd/system/sockets.target.wants/cups.socket -> /usr/lib/systemd/system/cups.socket # systemctl list-unit-files | grep cups cups.service enabled cupsd.service enabled cups.socket enabled ---------------------------------------------------------------------------- When a unit file does no longer exist (in this case /usr/lib/systemd/system/cups.path was moved away) then "systemctl --force reenable" removes the broken symlink and the unit is no longer enabled (the whole unit is removed). When a symlink points to a non-exitent target (in this case /etc/systemd/system/sockets.target.wants/cups.socket points to /usr/lib/systemd/system/cups.socket.no but /usr/lib/systemd/system/cups.socket exists) then "systemctl --force reenable" replaces the nonsense symlink with one that makes sense and the unit is enabled. Unfortunately there is no "systemctl --force disable" that would clean up symlinks and disables a unit: ---------------------------------------------------------------------------- # systemctl list-unit-files | grep cups cups.service enabled cupsd.service enabled cups.socket enabled # ln -sf /usr/lib/systemd/system/cups.socket.no /etc/systemd/system/sockets.target.wants/cups.socket # file /etc/systemd/system/sockets.target.wants/cups.socket /etc/systemd/system/sockets.target.wants/cups.socket: broken symbolic link to `/usr/lib/systemd/system/cups.socket.no' # systemctl --force disable cups.socket && echo ok ok # systemctl list-unit-files | grep cups cups.service enabled cupsd.service enabled cups.socket enabled # file /etc/systemd/system/sockets.target.wants/cups.socket /etc/systemd/system/sockets.target.wants/cups.socket: broken symbolic link to `/usr/lib/systemd/system/cups.socket.no' # systemctl --force reenable cups.socket && echo ok rm '/etc/systemd/system/sockets.target.wants/cups.socket' ln -s '/usr/lib/systemd/system/cups.socket' '/etc/systemd/system/sockets.target.wants/cups.socket' ok # systemctl disable cups.socket && echo ok rm '/etc/systemd/system/sockets.target.wants/cups.socket' ok # systemctl list-unit-files | grep cups cups.service enabled cupsd.service enabled cups.socket disabled ---------------------------------------------------------------------------- I.e. to clean up a disabled unit it seems one must use systemctl --force reenable systemctl disable -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=904215 --- Comment #36 from Johannes Meixner --- How the update works in case of disabled service: ----------------------------------------------------------------------------- # systemctl list-unit-files | grep cups cups.path disabled cups.service disabled cups.socket disabled # systemctl list-units | grep cups cups.service loaded active running CUPS Printing Service # rpm -Uhv binaries/cups-client-1.5.4-167.1.i586.rpm binaries/cups-libs-1.5.4-167.1.i586.rpm binaries/cups-1.5.4-167.1.i586.rpm Preparing... ################################# [100%] Updating / installing... 1:cups-libs-1.5.4-167.1 ################################# [ 17%] 2:cups-client-1.5.4-167.1 ################################# [ 33%] 3:cups-1.5.4-167.1 warning: /etc/cups/cupsd.conf created as /etc/cups/cupsd.conf.rpmnew ################################# [ 50%] Cleaning up / removing... 4:cups-1.5.4-12.13.1 ################################# [ 67%] /var/tmp/rpm-tmp.Zy23db: line 8: /etc/init.d/cups: No such file or directory 5:cups-client-1.5.4-12.13.1 ################################# [ 83%] 6:cups-libs-1.5.4-12.13.1 ################################# [100%] # systemctl list-unit-files | grep cups cups.service disabled # systemctl list-units | grep cups cups.service loaded active running CUPS Printing Service ----------------------------------------------------------------------------- Seems to really work well... -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=904215 --- Comment #39 from Johannes Meixner --- Mainly for my own information: Thomas Blume mentioned that "systemctl" only works when systemd is running so that the "systemctl" commands in my script may not work during initial system installation. Even if "systemctl" commands fail, it is no real issue because during initial system installation there should be no need to clean up systemd units and my script has an explicit 'exit 0' at the end so that even if commands in the script fail, the 'cups' RPM installation would finish successfully. -- You are receiving this mail because: You are on the CC list for the bug.