ExecStartPre

[slzbi]

Hallo und sorry wegen der Frage, aber kenne mich mit Linux nur ganz wenig aus.
Ich will beim Start des Systems folgende beiden Befehle ausführen.

So funktionieren die in der Console:
iw phy `iw dev wlan0 info | gawk '/wiphy/ {printf "phy" $2}'` interface add mon0 type monitor
ifconfig mon0 up

Wie muss ich die hier einfügen damit es läuft.
Mein Ansatz gibt die Meldung:

[Service]
ExecStartPre=/usr/bin/ifconfig mon0 up
StandardOutput=null


sudo systemd-analyze verify probemon.service
probemon.service: Command /usr/bin/ifconfig is not executable: No such file or directory

[TomL]

Könntest Du kurz erklären, wie die Ausgangssituation ist und was am Ende rauskommen soll? Nur das man erkennen kann, ob der Lösungsansatz überhaupt der richtige ist.

[slzbi]

Ich habe aus einem Hausautomatisierunngsforum einen Mqtt Service nachgebaut.
ExecStart=/home/pi/python/probemon/probemon.py -i mon0 --mac-info --ssid --mqtt

Der Service/Dienst setzt aber folgenden Befehl voraus:

iw phy `iw dev wlan0 info | gawk '/wiphy/ {printf "phy" $2}'` interface add mon0 type monitor

Nur wenn ich den vorher in der Console manuell ausführe, funktioniert es.

Daher dachte ich mir, dass ich den Befehl vorher mit im Dienst ausführe.

Wenn es einen anderen Weg gibt, dass das dauerhaft automatisch ausgeführt wird bei Start, gerne auch so lösen

[TomL]

Ich kann das leider hier (mangels passender Umgebung) nicht "nachspielen", hätte aber eine Idee, die funktionieren könnte. Ich würde das notwendige in ein Script auslagern, dort alles notwendige veranlassen/tun und dann von der Service-Unit nur das Script starten. Was jetzt wirklich im Script notwendig ist... keine Ahnung, Du hast den Ablauf leider verschwiegen.... also ein Vorschlag nur auf Verdacht:

cat /usr/local/bin/probemon

Code: Alles auswählen

#!/bin/bash
iw phy $(iw dev wlan0 info | gawk '/wiphy/ {printf "phy" $2}') interface add mon0 type monitor
/usr/bin/ifconfig mon0 up
exit 0

cat /etc/systemd/system/probemon.service

Code: Alles auswählen

[Unit]
Description=Irgendeine Beschreibung
DefaultDependencies=no
After=basic.target

[Service]
Type=simple
RemainAfterExit=yes
ExecStart=/usr/local/bin/probemon

[Install]
WantedBy=multi-user.target

Dann die Rechte für beide Files setzen, zuerst als Test von Hand starten, wenn keine Fehler auftreten, dann enablen.

BTW: Wenn Du fragen hast, solltest Du nach Möglichkeit immer vollständige Infos beilegen... wenn es eine Service-Unit gibt, dann komplett mit Name, Speicherort, Inhalt und Fehlermeldung. Ansonsten bleibt das alles nur Rätselraten und man nähert sich einer Lösung nur auf unnötig komplizierten Umwegen. Ob meine Antwort zu den Anforderungen resp. Abhängigkeiten passt...?... keine Ahnung, kann man aufgrund der mageren Infos nur raten.

[slzbi]

Hallo Thomas,

folgendes getestet:

Shellskript erstellt:
#!/bin/bash
sudo iw phy `iw dev wlan0 info | gawk '/wiphy/ {printf "phy" $2}'` interface add mon0 type monitor
sudo ifconfig mon0 up
echo "ende"
exit 0

Das Shell Skript nach Reboot ausgeführt und danach eine Kontrolle durchgeführt, ob die Befehle laufen.
Alles ok.

Dann das Shell Skript wie folgt im Dienst eingestellt:
[Unit]
Description=Probemon MQTT Service

[Service]
ExecStart=/bin/bash /home/pi/skripte/autostart.sh
StandardOutput=null

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

Der Dienst wurde ohne Fehler gestartet, aber mein Kontrollstatement
sudo python /home/pi/python/probemon/probemon.py -i mon0 --mac-info --ssid --log --mqtt-broker 192.168.178.38 --mqtt-user xx --mqtt-password xx --mqtt-topic /SmartHome/Interface/WiFi/ProbeRequest
liefert hier nichts.

Kann es an einem Kontext liegen, der beim Start anders ist als wenn man das Shellskript manuell ausführt oder so?

[TomL]

Kann es an einem Kontext liegen, der beim Start anders ist als wenn man das Shellskript manuell ausführt oder so?

Ja, sicher, das kann eine Problemquelle sein. Via systemd-service-unit wird der Job unter UID 0 ausgeführt, ebenso laufen dort gestartete Dienste auch unter UID 0. Machst Du das gleiche im Terminal manuell und unter Deiner Anmeldung, läuft alles unter Deiner UID. Das hat durchaus auch Auswirkungen auf den xserver.

Man könnte jetzt testen, ob es funktioniert, in die Service-Unit den User-/Group-Parameter zu setzen. Alternativ könnte man auch testen, im Script die Schritte via pkexec unter Deiner UID auszuführen. Ich kenne die Anforderungen Deiner Software nicht, also kann ich auch nur ins Blaue schießen.

BTW: Source-Code oder andere technische Texte markieren und dann </> in der Toolbar anklicken... das formartiert den Text mit konstanter Schriftgröße und hebt ihn hervor, vor dem normalen Text.... siehe wie in meinem Vorposting.

[slzbi]

Kannst Du mir jeweils ein Beispiel machen für die Alternativen?
a) in die Service-Unit den User-/Group-Parameter zu setzen
b) im Script die Schritte via pkexec unter Deiner UID auszuführen
Woher kenne ich meine UID überhaupt? Wäre das hier rüber ermittelbar? id -u username
Wäre die ID nach jedem Start dieselbe?

[TomL]

Hier https://www.freedesktop.org/software/sy ... vice.html# findest Du Beispiele (z.B Example 5) und Infos über "user=" . Das kommt in die [Service]-Section.

Ein Beispiel, um im Terminal als Root den Midnight-Commander unter meiner UID laufen zu lassen:

Code: Alles auswählen

root@thomaspc:~
# /usr/bin/pkexec -u thomas mc

[JTH]

Ein Berechtigungs-/Benutzerproblem beim Ausführen des Services würd ich hier eher nicht sehen. Dein kurzes Skript läuft, wenn beim Boot als Service ausgeführt, als root und das ist, da iw benutzt wird, auch notwendig. In dem kurzen Skript selbst wird sudo benutzt, also auch Ausführung von iw als root.

Verbesserungsvorschlag: Nimm das sudo aus dem Skript heraus, beim Boot ist es wie gesagt nicht notwendig. Wenn du das Skript danach nochmal manuell ausführen willst, geht das per

Code: Alles auswählen

$ sudo /home/pi/skripte/autostart.sh

Eine zweite Anmerkung am Rande:

ExecStart=/bin/bash /home/pi/skripte/autostart.sh

Das /bin/bash ist da nicht nötig, wenn dein Skript ausführbar ist und mit der Zeile #!/bin/bash (tut es ja) anfängt.


Wie Thomas schon geschrieben hat, wären alle die (?) Services und Skripte, die du gerade probierst, komplett und inklusive Dateinamen einmal hilfreich. Es mag sein, dass das hier

Alias=probemon.service

mit einem eventuellen zweiten Service (?) bei dir kollidiert, der genauso heißt.


Zu deinem allerersten Beitrag:

probemon.service: Command /usr/bin/ifconfig is not executable: No such file or directory

ifconfig liegt in /usr/sbin, da es ein normaler Benutzer mangels Berechtigungen nur sehr eingeschränkt benutzen kann.

[TomL]

Ein Berechtigungs-/Benutzerproblem beim Ausführen des Services würd ich hier eher nicht sehen.

Ich auch nicht. Mein Hinweis zielte eher auf die spätere Verwendung von X-Anwendungen ab, die dann unter der UID des Users laufen. Wenn zuvor aber Vorbereitungen über eine Service-Unit unter der UID 0 getroffen wurden, kanns halt sein, dass es anschließend einfach nicht funktioniert. Aber wie schon bemerkt, ohne einen Gesamt-Überblick weiss man nicht, welches Vorgehen schließlich richtig ist, man rätselt nur rum.

[slzbi]

Habe das jetzt hinbekommen.
Und zwar habe ich die Befehle in die Datei etc/rc.local reingenommen.
Das funktioniert.

Jetzt ist es aber so, dass ich in dem Dienst mein mqtt aufrufe.

Code: Alles auswählen

/home/pi/python/probemon/probemon.py -i mon0 --mac-info --ssid --mqtt-broker 192.168.178.38 --mqtt-user openhabian --mqtt-password openhabian --mqtt-topic /SmartHome/Interface/WiFi/ProbeRequest

Der Dienst scheint aber zeitlich vor der rc.lcoal aufgerufen zu werden.
Da der Dienst die beiden Befehle aus der rc.lcoal aber benötigt, scheint der Fehl zuschlagen.
Habe daher in die rc.local noch mal einen expliziten Start des Dienstes mit aufgenommen.

Code: Alles auswählen

sudo systemctl start probemon.service

Geht das ggf. noch eleganter? Bzw. kann ich den Befehl aus dem Dienst auch direkt in der rc.local aufrufen?
Oder läuft der Befehl dann nur 1x?

[TomL]

Und zwar habe ich die Befehle in die Datei etc/rc.local reingenommen.

Dazu würde ich mich hieran orientieren:
https://unix.stackexchange.com/question ... reating-rc

Die rc.local ist eigentlich deprecated... oder auch outdated.... selbst wenn das jetzt vorübergehend noch funktionieren wird. Außerdem wird die rc.local auch nur "irgendwann" durch eine Service-Unit aufgerufen. Insofern ist es besser, eine eigene und besser in den Systemstart integrierte Service-Unit plus eigenem Script zu erstellen.

[pferdefreund]

Wenn es beim X-Start laufen soll, wie wäre es denn mit einer .xinitrc in deinem $HOME