systemd: Tagging /dev/virtio-ports/* for systemd

[Daniel P. Berrange]

On Tue, Jul 05, 2011 at 08:36:42PM +0200, Lennart Poettering wrote:
> On Tue, 05.07.11 16:54, Daniel P. Berrange (berrange at redhat.com) wrote:
> 
> Heya,
> 
> > On Tue, Jul 05, 2011 at 04:47:18PM +0100, Richard W.M. Jones wrote:
> > > [Is there a Fedora-specific systemd list?  Not that I can find.]
> > > 
> > > We'd like to request that virtio-serial devices (/dev/virtio-ports/*)
> > > are tagged so we can use them as systemd devices.  Dan Berrange thinks
> > > the right incantation is to add:
> > > 
> > > SUBSYSTEM=="virtio-ports", TAG+="systemd"
> > > 
> > > to /lib/udev/rules.d/99-systemd.rules
> > 
> > The goal is that we want to automagically run /usr/sbin/guestfsd
> > when /dev/virtio-ports/org.libguestfs.channel.0 is present. For
> > this I believe we need to have a '.device' unit for the virtio-port
> > device populated from the above udev rule, so we can in turn have a
> > guestfsd.service unit looking like:
> 
> I think adding such a rule to systemd's unit file is not a bad idea, but
> since the use case here is very specific to your app, another option
> would be to add an app-specific udev rule for this. (See below)
> 
> > [Unit]
> > Description=libguestfs management daemon
> > BindTo=dev-virtio\x2dports-org.libguestfs.channel.0.device
> > After=dev-virtio\x2dports-org.libguestfs.channel.0.device
> > 
> > [Service]
> > ExecStart=-/usr/sbin/guestfsd
> 
> Prefixing the binary path with "-" will result in the exit code of
> guestfsd be ignored, i.e. we wouldn't put the service into failed state
> if it crashes (or exits otherwise abnormally). I'd encourage never to
> prefix with "-" unless you have a really good reason to.
> 
> > Restart=always
> > RestartSec=0
> > 
> > [Install]
> > WantedBy=multi-user.target
> 
> If you use "WantedBy=multi-user.target" then this unit would be started
> at boot, and delayed until the device in question shows up. If it never
> shows up (for example because you boot on bare metal), then it would
> have to timeout, which wouldn't be particularly pretty.

Yeah, we don't really want a timeout on bare metal, or if the guest
doesn't have the device enabled.

> I wonder if it wouldn't be nicer to use the device showing up as _only_
> trigger to spawn the service. This would be nicer I think because it
> would spawn the service only if run in a VM. If you run the machine on
> bare metal, then it wouldn't be started at all, and would not have to
> timeout. (And if I grok this properly, then the virtio serial ports are
> even hotpluggable, which makes this even more interesting) To implement
> a scheme like that, you'd just ship a udev rules file which you install
> to /lib/udev/rules/99-guestfs.rules with contents
> like this:
> 
> SUBSYSTEM=="virtio-ports", ATTR{name}=="org.libguestfs.channel.0", TAG+="systemd", ENV{SYSTEMD_WANTS}="guestfsd.service"
> 
> (untested, I hope the match is right)
> 
> It's up to you whether you prefer the "spawn unconditionally but wait
> for the device to show up" approach or my suggestion of "spawn if and
> when the device shows up".

We do in fact want the latter 'spawn if and when the device shows up',
so we'll have a go with the udev rule you suggest above.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|