Bug 1149066 - daemon-reload does not always reload generated services
daemon-reload does not always reload generated services
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:
  Show dependency treegraph
 
Reported: 2019-09-01 08:03 UTC by Michal Suchanek
Modified: 2019-10-09 15:00 UTC (History)
1 user (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 Michal Suchanek 2019-09-01 08:03:49 UTC
# cryptsetup status usb
/dev/mapper/usb is inactive.
# cryptsetup open --key-file /etc/usbkey /dev/disk/by-uuid/98b904aa-5b37-476e-a690-5c73cc93a5b7 usb
# cryptsetup status usb
/dev/mapper/usb is active.
  type:    LUKS1
  cipher:  aes-xts-plain64
  keysize: 512 bits
  key location: dm-crypt
  device:  /dev/sda
  sector size:  512
  offset:  4096 sectors
  size:    30027776 sectors
  mode:    read/write
# cryptsetup close usb
# systemctl daemon-reload
# systemctl start systemd-cryptsetup@cr_usb.service 
Please enter passphrase for disk Cruzer_Fit (cr_usb): ^C
# cat /etc/crypttab 
cr_mmcblk0p3  UUID=c0587206-aaa9-4e93-98be-d7ee30d6b12c
cr_usb  UUID=98b904aa-5b37-476e-a690-5c73cc93a5b7 /etc/usbkey nofail

       Each line is in the form

           name encrypted-device password options

       The third field specifies the encryption password. If the field is not present or the password is set to "none" or "-", the
       password has to be manually entered during system boot. Otherwise, the field is interpreted as an absolute path to a file
       containing the encryption password.
Comment 1 Michal Suchanek 2019-09-01 11:05:52 UTC
 > cat /var/run/systemd/generator/systemd-cryptsetup@cr_usb.service 
# Automatically generated by systemd-cryptsetup-generator

[Unit]
Description=Cryptography Setup for %I
Documentation=man:crypttab(5) man:systemd-cryptsetup-generator(8) man:systemd-cryptsetup@.service(8)
SourcePath=/etc/crypttab
DefaultDependencies=no
Conflicts=umount.target
IgnoreOnIsolate=true
After=cryptsetup-pre.target
RequiresMountsFor=/etc/usbkey
BindsTo=dev-disk-by\x2duuid-98b904aa\x2d5b37\x2d476e\x2da690\x2d5c73cc93a5b7.device
After=dev-disk-by\x2duuid-98b904aa\x2d5b37\x2d476e\x2da690\x2d5c73cc93a5b7.device
Before=umount.target

[Service]
Type=oneshot
RemainAfterExit=yes
TimeoutSec=0
KeyringMode=shared
OOMScoreAdjust=500
ExecStart=/usr/lib/systemd/systemd-cryptsetup attach 'cr_usb' '/dev/disk/by-uuid/98b904aa-5b37-476e-a690-5c73cc93a5b7' '/etc/usbkey' 'nofail'
ExecStop=/usr/lib/systemd/systemd-cryptsetup detach 'cr_usb'
Comment 2 Michal Suchanek 2019-09-01 11:23:23 UTC
This is some bug with daemon-reload handling. The service was regenerated correctly as seen above but the previously loaded one with different key file was executed. Executing daemon-reload multiple times, possibly with some time passing in-between also loads the correct service definition.
Comment 3 Franck Bui 2019-09-06 07:03:38 UTC
(In reply to Michal Suchanek from comment #0)
> # systemctl daemon-reload
> # systemctl start systemd-cryptsetup@cr_usb.service 
> Please enter passphrase for disk Cruzer_Fit (cr_usb): ^C

My guess is that you just interrupted systemctl here but PID1 is still trying to activate the job you queued with systemctl.

systemctl was simply waiting for systemd-cryptsetup@cr_usb.service to be running. You killed it but this had no effects the queued job itself.

After pressing ^C, what does "systemctl status systemd-cryptsetup@cr_usb.service" show ?
Comment 4 Franck Bui 2019-10-09 15:00:36 UTC
I think the description I gave in comment #3 is what happened in your case and is then expected.

So I'm closing this bug.

In case you don't agree with this behavior please discuss this directly with upstream as this issue is not related to any SUSE specificity.