[systemd-devel] writing a systemd unit for nbd devices
Lennart Poettering
lennart at poettering.net
Mon Mar 24 11:46:48 PDT 2014
On Fri, 21.03.14 21:58, Wouter Verhelst (w at uter.be) wrote:
> > > In addition, nbd-client needs to fork() and open() the /dev/nbdX device
> > > to support partitioned NBD devices (due to a deadlock issue, that can't
> > > be done from the initial NBD_DO_IT ioctl handling, so it is done in the
> > > first open() instead).
> >
> > I don't follow here?
>
> I'm just trying to describe the full picture. I don't claim to
> understand systemd fully (yet, anyway), and want to make sure I'm not
> leaving things out that might be relevant -- even if they don't seem to
> be at first glance.
>
> Point being, I suspect the nbdXpY devices might need to be depended on
> (e.g., from whatever unit that mounts a file system), and then systemd
> would need to know how to "create" them. That would be by connecting the
> nbdX device, which then magically creates nbdXpY -- but only after the
> fork() and open() of the device; this could complicate things in a
> dependency/event-based system.
systemd will pick up all block devices (modulo the SYSTEMD_READY=
thing), so if nbd-client does enough to trigger the creation of the
partition devices, then systemd doesn't have to care for any specifics
here, it should just work...
> > Given your hint with the "pid" sysfs attribute, I think we should change
> > the nbd rule to be more like the loop rule, and actually bind
> > SYSTEMD_READY to the state in sysfs, rather than the type events
> > last received.
>
> Yes, that sounds reasonable.
Happy to take a bpatch for this, btw. Actually, I am kinda relying on
this, since I can't test this...
Lennart
--
Lennart Poettering, Red Hat
More information about the systemd-devel
mailing list