2

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.
Improve this question
5
  • I've updated the question with the requested output. Commented Dec 30, 2017 at 22:00
  • And the output of systemctl cat wpa_supplicant.service please. Commented Dec 30, 2017 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) Commented Dec 30, 2017 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. Commented Dec 30, 2017 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. Commented Dec 31, 2017 at 15:05

1 Answer 1

Reset to default
1

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

/etc/systemd/system/[email protected]:

[Unit] Description=WPA supplicant for %i [Service] ExecStart=/sbin/wpa_supplicant -i%i -c/etc/wpa_supplicant/wpa_supplicant.conf [Install] WantedBy=multi-user.target

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.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.