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?? _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
