dracut
dracut copied to clipboard
dracutdevs
Run systemd-sysusers when generating initrd
I was looking at https://github.com/dracutdevs/dracut/pull/1658 where we removed the Condition, so the sysusers are run every time in the initrd. I don't think this is necessary since we always take the same sysusers drop-ins and create the same users every time. I think it should be safe to call systemd-sysusers while generating the initrd. We will move the module to the end of the queue and use systemd-sysusers --root. This should result in smaller initrd (no need for sysusers binary in the initrd) and faster boot (no need to create the users every time).
I am willing to write a patch for this, but first, I want to check what others think.
Such a patch would then have to use the systemd sysusers files that we are shipping with our modules ( and being shipped with modules that reside outside our own repository ) not anything that resides on the host system itself since there is no guarantee that those files exist there in the first place.
Quite frankly I'm not seeing how such a patch will not end up being more of a mess then just keeping things as they are ( with the cons it has ) since in the end of the day we serve plethora of systemd based distribution which are in various stages of implementation of systemd in them ( Debian vs Arch for example ) as well as we also need to make sure that dracut ( and it's modules ) for none systemd based distro's behave the same ( void, gentoo, debian as well etc. ) which requires the none systemd based modules to generate the users/groups in the same manner ( equivalent to how systemd does it ).
Such a patch would then have to use the systemd sysusers files that we are shipping with our modules ( and being shipped with modules that reside outside our own repository ) not anything that resides on the host system itself since there is no guarantee that those files exist there in the first place.
I think you misunderstood my proposal. I want all dracut modules to copy their dropins to initrd (as they do now) and then just call systemd-sysusers at the end on them (not the host's ones).
Quite frankly I'm not seeing how such a patch will not end up being more of a mess then just keeping things as they are ( with the cons it has ) since in the end of the day we serve plethora of systemd based distribution which are in various stages of implementation of systemd in them ( Debian vs Arch for example ) as well as we also need to make sure that dracut ( and it's modules ) for none systemd based distro's behave the same ( void, gentoo, debian as well etc. ) which requires the none systemd based modules to generate the users/groups in the same manner ( equivalent to how systemd does it ).
There is literally no difference between the current state and my proposal. Right now we gather the dropins into the initrd and generate the users on every boot. I am just saying, that this is redundant since you can do it just once when initrd is created.
And also to back up my proposal. In a normal system we have ConditionNeedsUpdate just because we need to run the service when etc or usr change. Those are static in initrd.
Yup completely misunderstood you proposal and your proposal has now a solid go from me. One thing I would like to add I'm not so sure we can do it just once as in when the initrd is created however we can easily introduce a new kernel commandline switch (rd.create.sysusers= or whatever ) and add that as a condition in the type unit file ( ConditionKernelCommandLine=rd.create.sysusers=0 ) to trigger the unit and provide backwards compatibility to existing behaviour since when "ConditionNeedsUpdate" got added to the unit in upstream systemd, it broke existing system for users, using the dracut sysuser module in the wild so someone is doing something with it and might be relying on that behaviour. ( my best guess would be something stateless releated but I dont care, unlike upstream systemd I dont make assumption how people are using dracut modules or in/for what purpose )