When running systemd, dbus should use the 'SystemdService=' entry in the dbus service file (/usr/share/dbus-1/system-services/fi.*) to let systemd start the needed unit. Steps to reproduce: 1. Disable the wpa_supplicant services via systemctl so they don't start if not needed. That is, there should be no symlink in any /etc/systemd/system/*.target directory to wpa_supplicant*.service. 2. Restart. 3. Use networkmanager or similar tool to use the wpa_supplicant dbus interface. Actual Results: wpa_supplicant is started by dbus, ignoring the wpa_supplicant.service unit file for systemd. This can also be seen by running 'systemd-cgls' and observing that wpa_supplicant is in the dbus cgroup. Expected Results: systemd should start and manage wpa_supplicant in its own cgroup. Suggested Solution: Append 'SystemdService=wpa_supplicant.service' to both /usr/share/dbus-1/system-services/fi.* files.
Please reassign this bug to who ever handles systemd stuff, this hasn't got anything to do with wpa_supplicant from what I can tell.
Henry, could you prepare a patch?
Ping.
Created attachment 291011 [details, diff] Let dbus ask systemd to start wpa_supplicant when systemd is used Thanks for reminding me. This patch adds the necessary entry in both dbus service files of wpa_supplicant. It is a shorter version of the one accepted upstream (http://hostap.epitest.fi/gitweb/gitweb.cgi?p=hostap.git;a=commit;h=2ecaec50c8eb772e131b6c468b60edbcc00e660c). Should I also prepare a patch for the ebuild?
(In reply to comment #4) > Created attachment 291011 [details, diff] > Let dbus ask systemd to start wpa_supplicant when systemd is used > > Thanks for reminding me. This patch adds the necessary entry in both dbus > service files of wpa_supplicant. It is a shorter version of the one accepted > upstream > (http://hostap.epitest.fi/gitweb/gitweb.cgi?p=hostap.git;a=commit;h=2ecaec50c8eb772e131b6c468b60edbcc00e660c). > > Should I also prepare a patch for the ebuild? I'll handle it from that. But I'd appreciate if you submitted upstream a patch fixing those .service files not to use network.target and multi-user.target instead. This is incorrect, network.target is special.
+ 27 Oct 2011; Michał Górny <mgorny@gentoo.org> + wpa_supplicant-0.7.3-r5.ebuild: + Add systemd service name to D-Bus service files per bug #372877. +
(In reply to comment #5) > (In reply to comment #4) > > > > Should I also prepare a patch for the ebuild? > > I'll handle it from that. Nah, with USE="wimax" it fails with the following: tee: dbus/*.service: No such file or directory > > But I'd appreciate if you submitted upstream a patch fixing those .service > files not to use network.target and multi-user.target instead. This is > incorrect, network.target is special. Yes, I will. Can you explain to me how network.target is special? The man page (systemd.special) only mentions that it is special with respect to SysV init scripts, which are not used on Gentoo. Also, Fedora's wpa_supplicant has [Unit] After=syslog.target network.target I agree on adding syslog.target, but network.target seems weird, as wpa_supplicant may well be needed to establish network connectivity in the first place. What do you think?
(In reply to comment #7) > (In reply to comment #5) > > (In reply to comment #4) > > > > > > Should I also prepare a patch for the ebuild? > > > > I'll handle it from that. > > Nah, with USE="wimax" it fails with the following: > > tee: dbus/*.service: No such file or directory Ah, sorry, missed the 'cd'. Now it should work. > > But I'd appreciate if you submitted upstream a patch fixing those .service > > files not to use network.target and multi-user.target instead. This is > > incorrect, network.target is special. > > Yes, I will. Can you explain to me how network.target is special? The man page > (systemd.special) only mentions that it is special with respect to SysV init > scripts, which are not used on Gentoo. Well, that's what systemd guys told me on IRC. Take a look at NetworkManager service files [1,2]. The idea is that network.target is up when network is actually ready (i.e. delayed). I'd say that's task of a multi-tool like NetworkManager or DHCP daemon at least. > Also, Fedora's wpa_supplicant has > > [Unit] > After=syslog.target network.target > > I agree on adding syslog.target, but network.target seems weird, as > wpa_supplicant may well be needed to establish network connectivity in the > first place. What do you think? Yes, that's weird indeed. [1]:http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/data/NetworkManager.service.in [2]:http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/data/NetworkManager-wait-online.service.in