Bug 1149066

Summary:	daemon-reload does not always reload generated services
Product:	[openSUSE] openSUSE Tumbleweed	Reporter:	Michal Suchanek <msuchanek>
Component:	Basesystem	Assignee:	systemd maintainers <systemd-maintainers>
Status:	RESOLVED INVALID	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None	CC:	fbui
Version:	Current
Target Milestone:	---
Hardware:	Other
OS:	Other
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

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.