[solved] wpa_supplicant following system update

Looking at friend's monitor (running Arch), I saw his clock was behind, so I wanted to # ntpdate pool.ntp.org his system. It turned-out ntp hadn't been installed. I started with #pacman -S ntp, but dependency errors appeared -- the typical sign that a system needs updating. So, # pacman -Syu, and sure enough, it was at leas 4GB out of whack. Afterwards, all was good for adding ntp and running ntpdate. His clock updated.

The problem was, the first time he cycled power, his wifi didn't connect. I found I could easily connect his system manually (CLI) with

# wpa_supplicant -Dwext -iwlp1s0 -c/etc/wpa_supplicant/wpa_supplicant.conf &

or better...

# wpa_supplicant -Dnl80211 -iwlp1s0 -c/etc/wpa_supplicant/wpa_supplicant.conf &

So, WTF? One possibility was that, beginning in 2016, dhcpcd stopped connecting its built-in wpa_supplicant hook during dhcpcd install. It has to be done manually. There's also a second option, giving at least two solutions.

two solutions

1. # systemctl disable wpa_supplicant.service
   # cp /usr/share/dhcpcd/hooks/10-wpa_supplicant /lib/dhcpcd/dhcpcd-hooks

   This puts dhcpcd in charge, calling and restarting wpa_supplicant, as needed. Make sure the right PID directory (if needed) and password are in /etc/wpa_supplicant/wpa_supplicant.conf, so it can negotiate security. Also, if dhcpcd is hanging looking for an IPV6 connection, a person can add the "-4" flag to the "ExecStart" command in /usr/lib/systemd/system/dhcpcd.service. Problem solved; back to rock solid wifi connection.
2. Instead of putting dhcpcd in charge, put wpa_supplicant in charge, calling dhcpcd. This is not recommended since it requires a bunch of complicated custom shit described below

unit file

I checked systemd (systemctl list-unit-files) and, as expected, I saw that wpa_supplicant was no longer enabled. When I enabled wpa_supplicant, it created symlinks which were not straightforward ("epitest.fi"?), which I did not trust as helpful. So I wrote him a straightforward service unit file specific for initializing his wifi:

# nano /etc/systemd/system/johndoewifi.service

# custom wifi connect
# Arch location: /etc/systemd/system/johndoewifi.service
[Unit]
Description=wpa_supplicant wext wifi
Wants=network.target
After=network.target
# Before=network.target

# execute and run in background
[Service]
Type=forking
PIDFile=/var/run/wpa_supplicant.pid
ExecStart=/usr/bin/wpa_supplicant -Dwext -iwlp1s0 -c/etc/wpa_supplicant/wpa_supplicant.conf
# ExecStop=/usr/bin/wpa_supplicant -x

[Install]
WantedBy=multi-user.target

restart from user

You can get wpa_supplicant to run from user, with eg

# nano /etc/wpa_supplicant/wpa_supplicant.conf
# Allow users in the 'wheel' group to control wpa_supplicant
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel

If John Doe is in the wheel group he can start wpa_supplicant no problema. However, it will fail, since he doesn't have authority to bring the interface UP or DOWN from userspace. That requires another kludge.
(source: Gentoo wiki)