systemd service zum An/Abschalten von WLan Interface geht nicht

[irmacapuzzi]

Ich habe eine kleinen ARM SBC an dem ich über gpios die USB-Ports an und ab schalten kann, an einem Port hängt eine RTL8191S WLankarte.
Ich habe /root/wlan_start.sh was den USB Port anschaltet, und dann sobald wlan0 in $ip a auftaucht $ifup wlan0 aufruft.
Dieses wird von /root/USB_STARTUP.sh aufgerufen sobald Kontrolle über die USB-Ports besteht (gpio ports exportiert sind), (A) soll von einem systemd service usb-startup aufgerufen werden.

usb-startup.service:

Code: Alles auswählen

[Unit]
Description=enable control over USB-Ports and start WLan

[Service]
ExecStart=/root/USB_STARTUP.sh

[Install]
WantedBy=default.target

(ich hab unter Service auch schon Type=oneshot,simple,forking ausprobiert(edit: forking scheint jetzt auch die Lösung zu sein))

Wenn ich /root/USB_STARTUP.sh direkt aufrufe geht alles gut, in ip a ist wlan0 up und IPv4 ist konfiguriert, IPv6 nicht.
Wenn ich $systemctl start usb-startup aufrufe wird sowohl IPv4 als auch IPv6 konfiguriert und wlan0 geht nach kurzer Zeit (<1s) wieder down

relevanter Teil meiner /etc/network/interfaces:

Code: Alles auswählen

auto wlan0
iface wlan0 inet dhcp
	wireless-essid any
	pre-up wpa_supplicant -D wext -i wlan0 -c /boot/wpa_supplicabt.conf -B
	post-down killall -w wpa_supplicant

Ich kann sonst noch Logs posten, auch von hostapd oder dnsmasq am WLan-AP wenn das hilft.

[TomL]

1. Poste mal das Script a.
2. Ich würde das nicht über die Interfaces lösen, sondern die WLAN-Verbindung auch über eine Service-Unit herstellen

[irmacapuzzi]

Script A (/root/USB_STARTUP.sh):

Code: Alles auswählen

#!/bin/bash
/bin/bash /root/USB_CTRL_ENABLE.sh
/bin/bash /root/USBB_DIS.sh
/bin/bash /root/wlan_start.sh

USB_CTRL_ENABLE exportiert die 2 GPIOs zur Steuerung der Ports
USBB_DIS disabled den 2. Port an dem etwas anderes dran hängt

Script B (/root/wlan_start.sh):

Code: Alles auswählen

#!/bin/bash
/bin/bash /root/USBC_EN.sh
while [ -z "$(ip a | grep wlan0)" ]
do
	sleep 1
done
sleep 1
ifup wlan0

USBC_EN enabled den Port mit der WLAN Karte

WLAN über Service-Unit herstellen schau ich mir mal an

[TomL]

Die Fehlersuche ist natürlich nur im Originalscript möglich... in einer aus der Erinnung gebildeten Vielleichtversion oder einer Annäherungsversion zu suchen und Vermutungen anzustellen bringt nicht viel. Zumindest hier fällt mir auf, dass die Scripte nicht mit einem exit-Code enden, der für systemd-Service-Units notwendig ist.

[irmacapuzzi]

Ok, hab die Skripte im vorherigen Post jetzt aktualisiert, musste noch vor alle Skriptaufrufe ein /bin/bash packen, und in /root/wlan_start.sh kam ein $ sleep 1 vor dem $ ifup wlan0 hinzu.
Hab jetzt mal ein $ exit 0 hinten an die Skripte gehangen, hab auch beim Service file ein wenig rumgespielt, sieht aus als würde es jetzt mit Type=forking klappen, vorher war es wohl simple weil nicht weiter spezifiziert.

Code: Alles auswählen

[Unit]
Description=enable control over USB-Ports and start WLAN

[Service]
Type=forking
ExecStart=/root/USB_STARTUP.sh

[Install]
WantedBy=default.target

Hab auch noch ein $ ifdown wlan0 in /root/wlan_start.sh eingebaut:

Code: Alles auswählen

#!/bin/bash
ifdown wlan0
/bin/bash /root/USBC_EN.sh
while [ -z "$(ip a | grep wlan0)" ]
do
	sleep 1
done
sleep 1
ifup wlan0

[TomL]

Sei mir nicht böse, aber ich emfpinde die Postings als unzumutbar zu lesen.... ich verstehe echt nur Bahnhof. Du schreibst zwar Script A und Script B,aber ich finde nirgends einen Aufruf , wie z.B. /usr/local/bin/a.sh oder /usr/local/bin/b.sh. Stattdessen gibts da ganz andere Scripte, die wieder ganz anders heissen.... irgendwie kann ich da absolut keine Zusammenhänge erkennen. Warum steht nicht nicht bei jedem Code-Schnippsel dabei, wo der Code herkommt? Du müsstest Dir mehr Mühe für Eindeutigkeit machen, statt zu überlegen, wie man die Zusammenhänge mit zusammenhanglosen Name wie a und b verschleiert.

Hier mal ein Beispiel wie es aussehen müsste, um Pfad, Name und Inhalt eindeutig erkennen zu können, um darüber bei mehreren Dateien dann auch die Zusammenhänge zu verstehen. Also, hier in diesem Beispiel sind Pfad, Name und Inhalt eindeutig und alles ist unzweifelhaft erkennbar.... ein vernebelndes Pseudonym wie A oder B ist hier nicht notwendig und auch nicht hilfreich.

Code: Alles auswählen

# cat /etc/systemd/system/sshd.service

[Unit]
Description=OpenBSD Secure Shell server
Documentation=man:sshd(8) man:sshd_config(5)
After=network.target auditd.service
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run

[Service]
EnvironmentFile=-/etc/default/ssh
ExecStartPre=/usr/sbin/sshd -t
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
ExecReload=/usr/sbin/sshd -t
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartPreventExitStatus=255
Type=notify
RuntimeDirectory=sshd
RuntimeDirectoryMode=0755

[Install]
WantedBy=multi-user.target
Alias=sshd.service

Warum startest Du für jeden Befehl in dem Script mit dem Namen A eine neue Bash....?... ich nehme mal an, dass das Script A heisst ...

Code: Alles auswählen

cat /pfadnachnirgendwo/a.sh

#!/bin/bash
/bin/bash /root/USB_CTRL_ENABLE.sh
/bin/bash /root/USBB_DIS.sh
/bin/bash /root/wlan_start.sh

So wärs auch okay:

Code: Alles auswählen

cat /pfadnachnirgendwo/a.sh

#!/bin/bash
/root/USB_CTRL_ENABLE.sh
/root/USBB_DIS.sh
/root/wlan_start.sh

[irmacapuzzi]

Hab die echten Skript-namen in Klammern dahinter geschrieben vor dem jeweiligen Code-block.
Ich hab das /bin/bash dazu geschrieben damit es immer noch funktioniert, auch wenn z.B. die Ausführungsrechte verloren gehen, oder der Shebang der Skripte unter die Räder kommt.

Ich werde mal kurz alle Erwähnungen von Skript A -> /root/USB_STARTUP.sh , Skript B -> /root/wlan_start.sh zur Klarheit ersetzen, tut mir wirklich leid das es so verwirrend zu lesen war.
Vielleicht möchtest du diese Namensersetzungen für Leser auch bei deinen Posts durchführen.

[TomL]

Eigentlich hätte ich jetzt erwartet, dass Du einmal die betroffenen Scripte mit vollständigen und reproduzierbaren Angaben und in logischer Reihenfolge in ein Posting untereinander wegschreibst.... mit Hinweisen, was wann von wem wodurch ausgelöst werden soll. Mit ständig rauf und runterscollen und jeweils ein möglicherweise betroffenes Posting mühsam suchen , wo man vielleicht was findet oder auch nicht, ist eigentlich unzumutbar, weil keiner Deine Gedanken und Zielvorgaben kennt. Rätselraten und Orakeln ist nicht mein Ding.

Nur eins noch... wenn es sich um eine persistente Wlan-Verbindung handelt, die immer wiederkehrend aufgebaut werden soll, würde ich das auf gar keinen Fall über die /etc/network/interfaces und irgendwelche mysteriösen Abläufe lösen, sondern effektiv in einer expliziten service-Unit, wie im folgenden Beispiel, in dem die Zugangs-Daten für den Accesspoint in der Datei tomsap.conf ausdrücklich und exklusiv hinterlegt sind:

Code: Alles auswählen

# cat /etc/systemd/system/connect_wlan0.service

[Unit]
Description=Wireless network connectivity (Interface=wlan0)
Wants=network.target
After=network.target

[Service]
Type=oneshot
RemainAfterExit=yes

ExecStart=/sbin/ip link set dev wlan0 up
ExecStart=/sbin/wpa_supplicant -B -i wlan0 -c /etc/wpa_supplicant/tomsap.conf
ExecStart=/sbin/dhclient wlan0

ExecStop=/sbin/ip link set dev wlan0 down

[Install]
WantedBy=multi-user.target

Ich hab das /bin/bash dazu geschrieben damit es immer noch funktioniert, auch wenn z.B. die Ausführungsrechte verloren gehen, oder der Shebang der Skripte unter die Räder kommt.

Das sollte eigentlich nicht passieren, wenn die Scripte da stehen würden, wo sie m.M.n. hingehören.... und zwar nach /usr/local/bin. Wenn die Eigentums-Rechte für dir Scripte dort root:root sind und die Verwendungs-Rechte 755, können sie problemlos von allen gestartet werden, auch möglicherweise unter einer UID von unberechtigten Benutzern, was für manche Sachen durchaus zu empfehlen ist, aber sie können von niemanden verändert werden. Im Verzeichnis /root hat nur root Lese-Rechte, deswegen halte ich dieses Verzeichnis für solcherart Scripte für die falsche Wahl.

[irmacapuzzi]

/etc/systemd/system/usb-startup.service:

Code: Alles auswählen

[Unit]
Description=enable control over USB-Ports and start WLAN

[Service]
Type=forking
ExecStart=/root/USB_STARTUP.sh

[Install]
WantedBy=default.target

/root/USB_STARTUP.sh:

Code: Alles auswählen

#!/bin/bash
/bin/bash /root/USB_CTRL_ENABLE.sh
/bin/bash /root/USBB_DIS.sh
/bin/bash /root/wlan_start.sh
exit 0

/root/wlan_start.sh:

Code: Alles auswählen

#!/bin/bash
ifdown wlan0
/bin/bash /root/USBC_EN.sh
while [ -z "$(ip a | grep wlan0)" ]
do
	sleep 1
done
sleep 1
ifup wlan0

Abschnitt von /etc/network/interfaces den ich zu Zeit benutze, aber wenn ich den connect_wlan0.service umgesetzt habe wohl wegschmeißen muss:

Code: Alles auswählen

auto wlan0
iface wlan0 inet dhcp
	wireless-essid any
	pre-up wpa_supplicant -D wext -i wlan0 -c /boot/wpa_supplicant.conf -B
	post-down killall -w wpa_supplicant

Problem scheint gelöst, nachdem /root/USB_STARTUP.sh ein exit 0 hat, und bei /etc/systemd/system/usb-startup.service Type=forking ist.
Ich werde noch den connect_wlan0.service umsetzen, danke dafür, ich nehme an dann muss ich den wlan0 Abschnitt aus /etc/network/interfaces löschen.

Später möchte ich den SBC suspenden, und in Intervallen in Größenordnung von 10min einen wakeup machen, die WLAN Karte anschalten und nach Netzwerken scannen, dann soll sie wenn sie nach 60s nichts findet wieder abschalten, und den SBC suspenden, das klappt auch schon recht gut, gehört aber meines Erachtens nicht mehr wirklich in dieses Topic.

[TomL]

Abschnitt von /etc/network/interfaces den ich zu Zeit benutze, aber wenn ich den connect_wlan0.service umgesetzt habe wohl wegschmeißen muss:

Ja, mit # einkommentieren reicht

Problem scheint gelöst, nachdem /root/USB_STARTUP.sh ein exit 0 hat, und bei /etc/systemd/system/usb-startup.service Type=forking ist.

Nein, ob forking oder simple ist egal, ein via service-unit gestartetes Script muss dem service-manager immer mitteilen, ob der Start erfolgreich war oder nicht... und das passiert mit exit 0. Ein fehlender Rückgabewert oder ein Rückgabewert ungleich 0 sorgt dafür, dass der Service gekillt wird... er könnte sich ja auch aufgehangen haben.

Btw, der Unit-Type 'forking' in diesem Beispiel ist m.M.n. auf jeden Fall verkehrt, weil der primäre Prozess sich nicht wegforkt... das passiert erst am Ende der Jobkette, und da auch noch aus Sicht des eigentlichen Jobs nur indirekt, weil erst ganz am Schluß ifup für einen Quasi-Prozess-Fork durch wlan_supplicant sorgt. 'simple' wäre hier meiner Meinung nach der richtige Unit-Type. Und mit exit 0 beenden (sofern der Ablauf bis zum exit 0 fehlerfrei war) ist auch hier die Lösung.

BTW, für Dein letztes Posting ein Beim nächsten Mal dann besser gleich so, dann spart man sich die unnütze Rumfragerei. Eindeutigkeit und Nachvollziehbarkeit des Problems ist das A und O um Problemlösungen zu finden. Und am meisten Spass machts, wenns am Anfang ein Problem gab und am Ende isses gelöst.

[irmacapuzzi]

Naja, mit Type=simple gehts halt nicht, ich hatte vorher auch schon forking probiert, aber da ging es noch nicht weil ich noch kein exit 0 hatte.
Zur Zeit ist wirklich Type=forking mit exit 0 im Skript das einzige was geht.
Vielleicht kann ich ja simple wieder benutzen wenn das wpa_supplicant im connect_wlan0.service läuft.

[irmacapuzzi]

Ach ja, zum connect_wlan0.service, ich werde ihn wlan0.service nennen.

Kann ich da noch das /root/USBC_EN.sh aus /root/wlan_start.sh unterbringen? Ich frage weil durch dieses Skript das USB-gerät überhaupt erst "angeschlossen" wird, dadurch dauert es nach Aufruf dieses
Skripts noch eine kurze Zeit bis wirklich wlan0 verfügbar ist, darum hatte ich in wlan_start.sh dieses Spinlock mit der while Schleife.
Könnte ich z.B. einen connect_wlan0.service (nicht deinen connect_wlan0.service, der soll bei mir ja wlan0.service heißen) machen der wenn er startet die WLAN-Karte anschließt, und dann exit 0 macht sobald
wlan0 wirklich verfügbar ist? Dann könnte wahrscheinlich wlan0.service warten darauf das connect_wlan0.service fertig ist.

Wenn diese Idee schlecht ist bitte sagen, die Problemstellung ist halt: Es vergeht Zeit zwischen WLAN-Karte anschließen und dem verfügbar werden von wlan0, das müsste ich irgendwie in Systemd umsetzen.

[TomL]

Vielleicht kann ich ja simple wieder benutzen wenn das wpa_supplicant im connect_wlan0.service läuft.

Nee, lass es so, wie es ist.... es funktioniert und damit ist es gut.

Kann ich da noch das /root/USBC_EN.sh aus /root/wlan_start.sh unterbringen?

Die Statements in der Service-Unit sind auch nur normale Shell-Befehle... statt der Unit kannst Du sie auch direkt 1:1 in das Script USBC_EN.sh an geeigneter Stelle einbauen, dann brauchst Du die Unit gar nicht.