[systemd-devel] Question about generators and adding new units in the middle of a transaction

Manuel Amador rudd-o at rudd-o.com
Fri Nov 4 05:22:56 PDT 2011


I am developing systemd support for ZFS:

https://github.com/zfsonlinux/zfs/pull/435/files

as you can see, I create the units early on bootup using a generator (a 
mechanism that is entirely undocumented, tsk).

Then systemd proceeds with normal system startup.

The whole point is to be able to mount file systems of other types on top of 
ZFS file systems, and then ZFS file systems on top of that.  This work lets 
this scenario work properly:

/ zfs
/blah ext4
/blah/blahblah zfs

But, here is a problem.  This works fine and dandy when ZFS has loaded the 
pools at boot through dracut or something, but will most assuredly fail if ZFS 
is not the root file system, as nothing will load the ZFS module.

We have some udev mechanisms at the moment to ensure that actually happens 
(loading of the zfs modules, importing of all pools).

Good and dandy so far.

Now, this will happen during udev settle.  What I want is to generate more 
units when pools are discovered and their file systems require to be mounted 
automatically.  That is, I need to re-run the generator and generate new 
units, and then tell systemd to daemon-reload.

But systemd is in the middle of a transaction, serving the unit local-
fs.target.  And, as you can imagine, the file systems that were discovered 
late, must be linked as wants of local-fs.target.

So my question is: what happens if I systemctl daemon-reload DURING the 
transaction that brings the system up?  Will systemd pick up the new units and 
add them as wants of local-fs.target?

ideal process:

root fs is mounted
starting local-fs.target
starting block device discovery
block dev discovered, import pool in block dev
oh, we found new file systems!
generate units for those
daemon-reload to add the new units as wants for local-fs.target
start all of these new units
and then, only then, local-fs.target will reach started state.

Is this even possible??


More information about the systemd-devel mailing list