systemd not starting wsdd + Fedora 31
See original GitHub issueHi,
Found your tool a couple days ago and I have run into an issue. When I manually run wsdd, it works great. When I reboot, systemd attempts to start it and fails to find a multicast address, or it binds to the virbr0 multicast address. When I disable libvirtd and reboot, it fails to find a usable multicast on eno1. When I specify which interface to use with the -i eno0
flag, it fails to find a usable multicast address to bind to.
After my system is fully booted and I am logged in, I can manually launch it with/without any flags I want and it will work no issues. I have also tried launching a cron job with @reboot
in crontab entry and that fails as well with same log output.
Here is my unit file:
# cat /etc/systemd/system/wsdd.service
[Unit]
Description=Web Services Dynamic Discovery host daemon
; Start after the network has been configured
After=network-online.target
Wants=network-online.target
; It makes sense to have Samba running when wsdd starts, but is not required
;Wants=smb.service
[Service]
Type=simple
ExecStart=/usr/bin/wsdd -i eno1 -w WOKRGROUP -vv
; Replace those with an unprivledged user/group that matches your environment,
; like nobody/nogroup or daemon:daemon or a dedicated user for wsdd
User=nobody
Group=nobody
; The following lines can be used for a chroot execution of wsdd.
; Also append '--chroot /run/wsdd/chroot' to ExecStart to enable chrooting
;AmbientCapabilities=CAP_SYS_CHROOT
;ExecStartPre=/usr/bin/install -d -o nobody -g nobody -m 0700 /run/wsdd/chroot
;ExecStopPost=rmdir /run/wsdd/chroot
[Install]
WantedBy=multi-user.target
here is ip addr show
# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether c0:3f:d5:68:2a:4b brd ff:ff:ff:ff:ff:ff
inet 10.0.0.150/24 brd 10.0.0.255 scope global dynamic noprefixroute eno1
valid_lft 603733sec preferred_lft 603733sec
inet6 2601:8c3:4001:3010:c23f:d5ff:fe68:2a4b/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 298sec preferred_lft 298sec
inet6 fe80::c23f:d5ff:fe68:2a4b/64 scope link noprefixroute
valid_lft forever preferred_lft forever
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
link/ether 52:54:00:46:a2:20 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
valid_lft forever preferred_lft forever
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000
link/ether 52:54:00:46:a2:20 brd ff:ff:ff:ff:ff:ff
With no args and libvirtd running I see this in the logs:
Apr 25 16:49:32 lakota audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=wsdd comm="systemd" exe="/usr/lib/systemd/systemd" ho>
Apr 25 16:49:32 lakota wsdd[1449]: 2020-04-25 16:49:32,945:wsdd WARNING(pid 1449): no interface given, using all interfaces
Apr 25 16:49:32 lakota wsdd[1449]: 2020-04-25 16:49:32,946:wsdd INFO(pid 1449): using pre-defined UUID ff1409e7-8867-51cc-8518-d51b72b8b322
Apr 25 16:49:32 lakota wsdd[1449]: 2020-04-25 16:49:32,954:wsdd DEBUG(pid 1449): ignoring loop-back interface lo
Apr 25 16:49:32 lakota wsdd[1449]: 2020-04-25 16:49:32,954:wsdd DEBUG(pid 1449): ignoring loop-back interface lo
Apr 25 16:49:32 lakota wsdd[1449]: 2020-04-25 16:49:32,954:wsdd DEBUG(pid 1449): ignoring loop-back interface lo
Apr 25 16:49:32 lakota wsdd[1449]: 2020-04-25 16:49:32,955:wsdd INFO(pid 1449): joined multicast group ('239.255.255.250', 3702) on 192.168.122.1%virbr0
Apr 25 16:49:32 lakota wsdd[1449]: 2020-04-25 16:49:32,956:wsdd DEBUG(pid 1449): transport address on virbr0 is 192.168.122.1
Apr 25 16:49:32 lakota wsdd[1449]: 2020-04-25 16:49:32,956:wsdd DEBUG(pid 1449): will listen for HTTP traffic on address ('192.168.122.1', 5357)
Apr 25 16:49:32 lakota wsdd[1449]: 2020-04-25 16:49:32,966:wsdd DEBUG(pid 1449): constructed xml for WSD message: b'<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:pnpx="http:>
Apr 25 16:49:32 lakota wsdd[1449]: 2020-04-25 16:49:32,966:wsdd DEBUG(pid 1449): scheduling Hello message via virbr0 to ('239.255.255.250', 3702)
with no libvirtd or specified interface it fails with:
-- Reboot --
Apr 25 17:26:16 lakota audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=wsdd comm="systemd" exe="/usr/lib/systemd/systemd" ho>
Apr 25 17:26:17 lakota wsdd[1371]: 2020-04-25 17:26:17,251:wsdd INFO(pid 1371): using pre-defined UUID ff1409e7-8867-51cc-8518-d51b72b8b322
Apr 25 17:26:17 lakota wsdd[1371]: 2020-04-25 17:26:17,265:wsdd DEBUG(pid 1371): ignoring loop-back interface lo
Apr 25 17:26:17 lakota wsdd[1371]: 2020-04-25 17:26:17,265:wsdd DEBUG(pid 1371): ignoring loop-back interface lo
Apr 25 17:26:17 lakota wsdd[1371]: 2020-04-25 17:26:17,266:wsdd DEBUG(pid 1371): ignoring loop-back interface lo
Apr 25 17:26:17 lakota wsdd[1371]: 2020-04-25 17:26:17,266:wsdd ERROR(pid 1371): No multicast addresses available. Exiting.
Apr 25 17:26:17 lakota systemd[1]: wsdd.service: Main process exited, code=exited, status=1/FAILURE
Apr 25 17:26:17 lakota systemd[1]: wsdd.service: Failed with result 'exit-code'.
I have looked through the previous issues and found some similar things, but nothing that is exactly what I am seeing. I have verified which branch I downloaded (master) and even tried a couple other branches and tried the Fedora 31 repo dnf install just to see if that helped. Nothing I have tried has fixed it.
Thanks in advance for your help.
Issue Analytics
- State:
- Created 3 years ago
- Comments:9 (5 by maintainers)
Top GitHub Comments
Thanks for reporting that issue.
TL;DR Essentially, it is similar to #18 but other reasons apply here. The solution appears to be discussion #25 and you should try the feat_discovery branch
My impression is the following. The IPv4 address on
eno1
is dynamic, e.g. an DHCP assigned address, I would say. Thus, there is a race condition. Systemd starts configures networking and pulls thenetwork-online.target
when the network management software thinks it is the appropriate to do so. But this does not mean, an usable address is available for wsdd. Anyways it is started because the unit file tells systemd exactly that. Since to address is available to wsdd it complains and terminates.When you enable libvirtd there is an address available when wsdd comes up, but if you restrict it again to use only
eno1
you end up with the situation above.The currently released version that is used by the distros out there is basically the master branch in most if not all cases. You can give the feat_discovery branch a try. You only need to replace the wsdd.py script (or wsdd “binary”, still the script but without extension) that was installed by the package manager with the one from discovery branch. It handles changes in network interfaces/addresses so it first starts up and waits for an address to become available.
Thanks for your support in investigating the issue. Your latest log looks good. This is, on the one hand, good because that’s what I expected 😉. But on the other hand it’s not so good because there might be still an issue under the hood which we where not able to uncover. Nevertheless, your problem disappeared. Therefore, I’m closing that issue. If any problem appears, just open a ticket again.