The spice-webdavd.service should be started by default if running inside a VM. (this is a service bound to a virtio port, with a udev rule, just like #876237)
Hm, unless I'm entirely confused, hardware activation doesn't require the unit to be enabled. https://bugzilla.redhat.com/show_bug.cgi?id=876237#c6 seems wrong.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #1) > Hm, unless I'm entirely confused, hardware activation doesn't require the > unit to be enabled. https://bugzilla.redhat.com/show_bug.cgi?id=876237#c6 > seems wrong. Last time I checked, I needed it in system preset (on f20) or it would not start on boot.
What is mostly likely going on is the following: SYSTEMD_WANTS must be set when the device unit is *started*. The device is probably detected in initramfs, but we don't want spice-webdavd.service to be started there. SYSTEMD_WANTS is probably useless in this case, and should be removed, and the unit should be enabled using presets and ConditionVirtualization. I'll fire up a VM and check if that hypothesis is true.
OK, spice-vdagentd.service has [Install] WantedBy=spice-vdagentd.target, and the udev rule has SYSTEMD_WANTS=spice-vdagentd.target. So the preset *is* necessary, but it does not start spice-vdagentd.service by itself, it just causes it to be started when spice-vdagentd.target is started. This works, and we could follow the same pattern with spice-webdavd.service. Nevertheless, this arrangement has a few issues: 1. The indirection through spice-vdagentd.target is not particularly useful. It is unlikely that anyone would ever add new services to this target [*]. This is different than the indirection through printers.target which sounds much more general. 2. spice-vdagentd.target will not be pulled in if the module is built in, and the device is detected in initramfs. I'm compiling a kernel to test this. 3. SYSTEMD_WANTS=... should probably be replaced with SYSTEMD_WANTS+=.... [*] It does have one advantage: 'systemctl enable/disable spice-vdagentd.service' simply works. But there are other ways to do it: either 'systemctl mask spice-vdagentd.service' or 'yum remove spice-vdagentd' will work just as well.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #4) > OK, spice-vdagentd.service has [Install] WantedBy=spice-vdagentd.target, and > the udev rule has SYSTEMD_WANTS=spice-vdagentd.target. So the preset *is* > necessary, but it does not start spice-vdagentd.service by itself, it just > causes it to be started when spice-vdagentd.target is started. > > This works, and we could follow the same pattern with spice-webdavd.service. > Nevertheless, this arrangement has a few issues: > > 1. The indirection through spice-vdagentd.target is not particularly useful. > It is unlikely that anyone would ever add new services to this target [*]. > This is different than the indirection through printers.target which sounds > much more general. ok, can it be replace with the service then? > > 2. spice-vdagentd.target will not be pulled in if the module is built in, > and the device is detected in initramfs. I'm compiling a kernel to test this. that could be, how to handle cold plug then? > 3. SYSTEMD_WANTS=... should probably be replaced with SYSTEMD_WANTS+=.... no idea :) > [*] It does have one advantage: 'systemctl enable/disable > spice-vdagentd.service' simply works. But there are other ways to do it: > either 'systemctl mask spice-vdagentd.service' or 'yum remove > spice-vdagentd' will work just as well. Hmm, I think I'd prefer to keep the target in this case. Perhaps Hans wanted this as well. Adding him in cc.
It turns out I was wrong... systemd will start units in SYSTEMD_WANTS when it is reloaded and also during switch-root. So spice-vdagentd.target & spice-vdagentd.service are started properly when virtio_console is built-in. I tested the following setup and it works for me: 1. remove spice-vdagent.target 2. change /lib/udev/rules.d/70-spice-vdagentd.rules to: ACTION=="add", SUBSYSTEM=="virtio-ports", ENV{DEVLINKS}=="/dev/virtio-ports/com.redhat.spice.0", ENV{SYSTEMD_WANTS}="spice-vdagentd.service" 3. The preset for spice-vdagentd.target can be removed from systemd presets. Identical setup should work for spice-webdavd.service, assuming that it has a virtio device it can be bound to.
Hi, (In reply to Marc-Andre Lureau from comment #5) > (In reply to Zbigniew Jędrzejewski-Szmek from comment #4) > > [*] It does have one advantage: 'systemctl enable/disable > > spice-vdagentd.service' simply works. But there are other ways to do it: > > either 'systemctl mask spice-vdagentd.service' or 'yum remove > > spice-vdagentd' will work just as well. > > Hmm, I think I'd prefer to keep the target in this case. Perhaps Hans wanted > this as well. Adding him in cc. Right, also using a target is the documented and recommended way how to do hardware based activation with systemd, and the above is exactly why it is the recommended way. Regards, Hans
> Right, also using a target is the documented and recommended way how to do hardware based activation with systemd No not really. Lennart used an example with a target on the blog, but that's only because printers are special - you might want to do many different things when printer hardware is plugged in, possibly user defined tasks. In the case at hand a daemon should be started and that's about it. I'm not saying that the target is harmful, just that's it doesn't bring much benefit. And it would be nice to keep the configuration style of spice-vdagentd and spice-webdavd similar, so it is better to remove one target unit, than to add one target unit.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #8) > > Right, also using a target is the documented and recommended way how to do hardware based activation with systemd > > No not really. Lennart used an example with a target on the blog, but that's > only because printers are special - you might want to do many different > things when printer hardware is plugged in, possibly user defined tasks. In > the case at hand a daemon should be started and that's about it. > > I'm not saying that the target is harmful, just that's it doesn't bring much > benefit. And it would be nice to keep the configuration style of > spice-vdagentd and spice-webdavd similar, so it is better to remove one > target unit, than to add one target unit. ok, let's remove the target in webdavd
phodav-0.4-2.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/phodav-0.4-2.fc20
Package phodav-0.4-2.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing phodav-0.4-2.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-6000/phodav-0.4-2.fc20 then log in and leave karma (feedback).
phodav-0.4-2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.