[systemd-devel] udev rule with SYSTEMD_WANTS not working if included in initramfs
Hi, I have a problem with a udev rule which should start a service if a device (ttyS0) is detected. It uses the SYSTEMD_WANTS env. When the rule is present in /etc/udev/rules.d/ but not in the initramfs -- the service is properly activated. When the rule is present in both /etc/udev/rules.d/ and the initramfs -- the service is not activated (loaded inactive dead). In this case systemd's log says[1]: systemd[1]: sys-devices-pnp0-00:03-tty-ttyS0.device: sys-devices-pnp0-00:03-tty-ttyS0.device lost dependency Wants=foobar.service systemd[1]: foobar.service: foobar.service lost dependency WantedBy=sys-devices-pnp0-00:03-tty-ttyS0.device systemd[1]: foobar.service: foobar.service lost dependency ReferencedBy=sys-devices-pnp0-00:03-tty-ttyS0.device systemd[1]: sys-devices-pnp0-00:03-tty-ttyS0.device: sys-devices-pnp0-00:03-tty-ttyS0.device lost dependency References=foobar.service The rule worked for me with systemd v232 on an older Debian. Now with Debian Buster and systemd v241 it doesn't. I think it may be associated with a change introduced by a commit[2] described as: core: remove SYSTEMD_WANTS udev property configured dependencies at the right moment …and more generally with PR #7186 [3]. What does "the right moment" mean? Do I violate some implicit assumption by adding the udev rule to initramfs? BTW, it happens automatically because initramfs-tools copy all files from /etc/udev/rules.d/ to initramfs. Having the rule at such an early stage was not my objective. Should I move the rules file to some other location so it's not copied to initramfs? Should I add some other criterion to disable the rule during initramfs and allow it to execute during a later booting phase? Nevertheless, I am most interested in understanding why it does not work. Maybe the failure just correlates with the rule's presence in the initramfs but the direct cause is different? [1]: https://github.com/systemd/systemd/commit/c999cf385aee08295dc204d98585cb4001d08ade [2]: https://github.com/systemd/systemd/commit/38b9b72ec10fa8875b1b7c93bc7ca6b8a2d5486e [3]: https://github.com/systemd/systemd/pull/7186 -- Marcin Szewczyk http://wodny.org ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] consoled vs vlock -a
On Wed, Oct 08, 2014 at 03:05:24PM +0200, David Herrmann wrote: Hi On Wed, Oct 8, 2014 at 2:02 PM, syst...@wodny.org wrote: Hi, will a transition to consoled affect `vlock -a` which uses ioctl(...VT_SETMODE...) to prevent switching to another terminal? Will this functionality still work? No. You can use loginctl lock-sessions as replacement, though. OK. Thanks for info. -- Marcin Szewczyk http://wodny.org mailto:marcin.szewc...@wodny.borg - remove b / usuń b xmpp:wo...@ubuntu.pl xmpp:wo...@jabster.pl ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
