Bug 1145960 - systemd .path file is not properly activated on upgrade
systemd .path file is not properly activated on upgrade
Status: RESOLVED INVALID
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Basesystem
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: systemd maintainers
E-mail List
:
Depends on:
Blocks: 1095662
  Show dependency treegraph
 
Reported: 2019-08-16 19:56 UTC by Stanislav Brabec
Modified: 2019-08-28 00:42 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stanislav Brabec 2019-08-16 19:56:35 UTC
I just encountered a problem with activation of smartd_generate_opts.path:
- Path trigger works in fresh installation.
- Path trigger does not work on upgrade.

As everything seems to be correctly set up in the smartmontools package and in the systemd-presets-common-SUSE, I suppose that something is broken for .path files in the %service_add_post macro.


Details:

In past, Thorsten created smartd_generate_opts.path and smartd_generate_opts.service that should automatically activate /usr/lib/smartmontools/generate_smartd_opts whenever /etc/sysconfig/smartmontools changes.

It works perfectly on a fresh installation, but it seems to be broken on upgrade.

I was thinking that the correct solution is adding of
enable smartd_generate_opts.path
to /usr/lib/systemd/system-preset/95-default-SUSE.preset

But it was done.


How to reproduce:

Test 1 (works on fresh installation):

1) Make a fresh installation of Tumbleweed
(Note, in case of testing on virtual, you have to delete ConditionVirtualization=false from /usr/lib/systemd/system/smartd.service and add "-q never" to SMARTD_EXTRA_OPTS in /etc/sysconfig/smartmontools).

2) Edit /etc/sysconfig/smartmontools and start smartd (if needed).

Current result:
smartd is instantly restarted. = OK

Test 2 (broken on upgrade):

1) rpm -e smartmontools

2) Install any older version of smartmontools.

3) zypper in smartmontools (see note on virtualization above).

4) Edit /etc/sysconfig/smartmontools and start smartd (if needed).

Current result:
smartd is left intact. = BROKEN

Work-around:
systemctl enable smartd_generate_opts.path
systemctl start smartd_generate_opts.path


Notes:

When it starts to work, then
## Command:     /usr/lib/smartmontools/generate_smartd_opts
in /etc/sysconfig/smartmontools will become obsolete.

It makes sense to add ConditionVirtualization=false to smartd_generate_opts.service or smartd_generate_opts.path, as it is present in the main smartd.service.
Comment 1 Thorsten Kukuk 2019-08-19 06:21:14 UTC
No systemd unit (neiter services nor timer nor path files) are started during upgrade, they are only activated.
Same as in the past with init scripts: init scripts also got only enabled during upgrade, but never started.

And this is the correct behavior. Autostarting services during upgrade does more harm then help. Not every upgrade is done in a running system. For that reason, we did explicit forbid to autostart services during upgrade in the past.
Comment 2 Franck Bui 2019-08-27 13:33:56 UTC
Does comment #1 address your concern ?

If so can you please close this bug accordingly ?
Comment 3 Stanislav Brabec 2019-08-28 00:42:55 UTC
Confirming.

This testcase succeeds:

1) rpm -e smartmontools

2) Install any older version of smartmontools.

3) zypper in smartmontools (see note on virtualization above).

4) Reboot.

5) Edit /etc/sysconfig/smartmontools and start smartd (if needed).

=> This is a bit confusing, but expected behavior.