I simply do:

systemctl start wpa_supplicant

No errors --- I get a new prompt. Ok, so far, so good.

I check journalctl.

wpa_supplicant[622]: Successfully initialized wpa_supplicant

Nothing more, again, so far, so good.

But then, of course, when I check ps aux | grep wpa, I get nothing at all.

So, not only does systemctl fail to start it, fail to inform it wasn't started, but there is nothing in journalctl about any problem at all. Just that it was "successfully initialized".

If I manually start wpa_supplicant, e.g. with this:

wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -i wlan0

Then it starts up perfectly fine, and even successfully authenticates with the AP in the wpa_supplicant.conf file.

Apparently, I have no idea how to use systemd. But when I get no errors, warning, or even information, it is not exactly intuitive to me what the problem is, but then again, I'm not used to using systemd. I can imagine others would encounter the same or similar problems trying to use systemd, and become just as frustrated as I am.

This is for Kali Linux Rolling. 4.13.0-kali1-amd64, systemd 235, wpa_supplicant v2.4.

systemctl status wpa_supplicant

● wpa_supplicant.service - WPA supplicant
   Loaded: loaded (/lib/systemd/system/wpa_supplicant.service; enabled; vendor preset: disabled)
   Active: inactive (dead) since Sat 2017-12-30 22:57:47 CET; 1min 0s ago
  Process: 1267 ExecStart=/sbin/wpa_supplicant -B -c /etc/wpa_supplicant/wpa_supplicant.conf -i wlan0 (code=exited, st
 Main PID: 1267 (code=exited, status=0/SUCCESS)

Dec 30 22:57:46 w530 systemd[1]: Starting WPA supplicant...
Dec 30 22:57:46 w530 wpa_supplicant[1267]: Successfully initialized wpa_supplicant
Dec 30 22:57:47 w530 systemd[1]: Started WPA supplicant.
  • I've updated the question with the requested output. – AlphaCentauri Dec 30 '17 at 22:00
  • And the output of systemctl cat wpa_supplicant.service please. – GAD3R Dec 30 '17 at 22:36
  • The better question is why are they making wpa_supplicant daemonize on Kali. On ArchLinux you need to enable the unit with an instance for your interface otherwise its only started in dbus control mode (which is then used by networkmanager) – jdwolf Dec 30 '17 at 23:22
  • I could guess its exiting because of something in the config file? But thats about as far as I want to debug Kali. – jdwolf Dec 30 '17 at 23:25
  • I've modified it to include the -c and -B flag, because, without it, it doesn't even parse /etc/wpa_supplicant/wpa_supplicant.conf (nor /etc/wpa_supplicant.conf) at all. But I don't see how it is related to something in wpa_supplicant.conf, because, as I pointed out, if I execute the very same command verbatim on the command line, it executes and starts up fine, authenticating properly and running in the background. I would guess it has something about daemonizing properties which are perhaps not desired by systemd, and it doesn't understand what is going on. – AlphaCentauri Dec 31 '17 at 15:05

Do you have an non-dbus @-version of the service file? In Gentoo, it's called "wpa_supplicant@.service", which allows you to bind wpa_supplicant to a specific interface. If you don't, a sample wpa_supplicant@.service file is given:


Description=WPA supplicant for %i

ExecStart=/sbin/wpa_supplicant -i%i -c/etc/wpa_supplicant/wpa_supplicant.conf


The Gentoo service file is a little different (it has Requires, After, Before, and Wants parameters, and a different install alias), but otherwise works the same.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.