[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