On Mo, 10.12.18 13:53, Karel Zak (kzak@xxxxxxxxxx) wrote: 65;5402;1c > On Tue, Nov 27, 2018 at 07:16:04PM +0100, Stanislav Brabec wrote: > > Sami Kerola wrote: > > That said, > > > getting a clarification from Jochen would nice because otherwise we are > > > simply guessing. > > > > Jochen Keil already left SUSE and I have no contact e-mail to him. > > > > But I got complain that it is missing after migration of rfkill to util-linux: > > https://bugzilla.opensuse.org/show_bug.cgi?id=1092820 > > It seems the best would be to ask upstream systemd guys. Maybe it's > really Suse specific and maybe it's something we can support for more > distros. I don't know. > > All thread: > https://lore.kernel.org/util-linux/0ce3309a-009a-7c00-3a2c-e4917b894f8c@xxxxxxx/T/#m221ad50b88792236c10c507f9163b57761c254a7 Hmm, what's the usecase for this? I mean, "systemctl start rfkill-block@xyz.service" isn't that much nicer to type than "rfkill block xyz", no? In fact, quite the opposite I'd say... Or this is about enable/disabling rfkill at subsequent boot, using "systemctl enable rfkill-block@xyz.service"? This kinda conflicts with the save/restore logic systemd-rfkill@.service (as shipped with systemd) implements already. It might make sense to extend that tool slightly, for example by defining a udev property or so to check which can override the saved data statically. Or definining a kernel cmdline option to override the rfkill save/restore logic globally. But I am pretty sure that one should be careful with having two different packages run at boot to set the initial rfkill setting, because they will fight about it. Lennart -- Lennart Poettering, Red Hat
