Submission type

• Bug report
• Request for enhancement (RFE)

systemd version the issue has been seen with

229-3

Used distribution

Arch Linux ARM on armv7l, Linux 4.4.2-1

Situation

This is a Cubieboard2 (Allwinner A20) providing a wireless access point using hostapd by means of a wireless network USB dongle.

Hostapd service file shipped by the distribution:
/usr/lib/systemd/system/hostapd.service

[Unit]
Description=Hostapd IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenticator
After=network.target

[Service]
ExecStart=/usr/bin/hostapd /etc/hostapd/hostapd.conf
ExecReload=/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target

Drop-in snippet to delay the start of hostapd.service until the wireless network USB device is available:
/etc/systemd/system/hostapd.service.d/requiresdevice.conf

[Unit]
After=sys-subsystem-net-devices-wlan0.device
BindsTo=sys-subsystem-net-devices-wlan0.device

Drop-in snippet for automatic restart:
/etc/systemd/system/hostapd.service.d/restart.conf

[Service]
Restart=always
RestartSec=15

From time to time the wireless network is gone.
This is apparently due to the wireless network USB device becoming disconnected, and then being reconnected a few seconds later (as shown by dmesg).
Because of BindsTo=, systemd then stops hostapd.service (as shown by systemctl status hostapd.service).
Despite having configured an automatic restart, hostapd.service is not restarted by systemd after the wireless network device is available again.
In such a state, manually starting hostapd.service using "systemctl start hostapd.service" works flawlessly.

man systemd.service says:

When the death of the process is a result of systemd operation (e.g. service stop or restart), the service will not be restarted.

I assume systemd considers stopping a service due to BindsTo= and device loss as being a systemd operation, and therefore does not make any attempt to start it again.

In case of bug report: Expected behaviour you didn't see

hostapd.service being restarted after device rediscovery

In case of bug report: Unexpected behaviour you saw

hostapd.service stays in stopped state despite having an automatic restart configured

In case of bug report: Steps to reproduce the problem

Probably creating a dummy .service unit with After=, BindsTo= and Restart= that binds to a USB device that can be plugged/unplugged can reproduce this behavior (not tested).

Also see this post in the Arch Linux forums:
https://bbs.archlinux.org/viewtopic.php?id=209783

Possibly systemd should perceive a BindsTo= service that has been stopped due to device loss as "failed" instead of "stopped by systemd".
The reasoning being that you configure a service with BindsTo= because it should terminate by itself when its device(s) are gone, but fails to do so (hostapd), and you need systemd just to help the service program in doing what it should be doing by itself in the first place, namely failing.
Hence a service stop because of BindsTo= should be considered as the service having failed.