Systemd Service funktioniert nicht

[daniel.pernold]

Hallo Jens, hallo Leute,

wenn ich die SmartPi Services auf meinem Pi stoppen will, werden die Prozesse nicht beendet.

Code:

pi@smartpi:~ $ sudo service smartpi stop

pi@smartpi:~ $ ps -ef | grep smartpi
root       561     1  0 13:13 ?        00:00:00 su pi -c /usr/local/bin/smartpireadout
root       562     1  0 13:13 ?        00:00:00 su pi -c /usr/local/bin/smartpiserver
pi         663   562  0 13:13 ?        00:00:02 /usr/local/bin/smartpiserver
pi         665   561  1 13:13 ?        00:00:04 /usr/local/bin/smartpireadout
root       818     1  0 13:15 ?        00:00:00 su root -c /usr/local/bin/smartpimodbusserver
root       839   818  0 13:15 ?        00:00:00 /usr/local/bin/smartpimodbusserver
pi         967   788  0 13:19 pts/0    00:00:00 grep --color=auto smartpi

Habe gesehen, dass das Service folgendes implementiert:

Code:

[Unit]
Description=SmartPi
After=syslog.target network.target remote-fs.target nss-lookup.target systemd-journald-dev-log.socket


[Service]
Type=forking
ExecStart=/usr/local/bin/smartpi start
ExecStop=/usr/local/bin/smartpi stop
Restart=on-failure
StandardOutput=null
StandardError=null


[Install]
WantedBy=multi-user.target

Wenn ich die Binary händisch ausführe, werden die Prozesse gestoppt (aber danach wieder von systemd gestartet).

Code:

pi@smartpi:~ $ sudo /usr/local/bin/smartpi stop
/usr/local/bin/smartpi: 13: echo: echo: I/O error
node-red: no process found
smartpi_check_umts.sh: no process found
smartpimodbusserver: no process found

pi@smartpi:~ $ ps -ef | grep smartpi
root       550     1  0 13:25 ?        00:00:00 /bin/bash /usr/local/bin/smartpi_check_umts.sh
pi         799   754  0 13:26 pts/0    00:00:00 grep --color=auto smartpi

pi@smartpi:~ $ ps -ef | grep smartpi
root       550     1  0 13:25 ?        00:00:00 /bin/bash /usr/local/bin/smartpi_check_umts.sh
root       821   550  2 13:27 ?        00:00:00 su pi -c /usr/local/bin/smartpiserver
root       828   550  2 13:27 ?        00:00:00 su pi -c /usr/local/bin/smartpireadout
root       834   550  2 13:27 ?        00:00:00 su root -c /usr/local/bin/smartpimodbusserver
pi         843   821  1 13:27 ?        00:00:00 /usr/local/bin/smartpiserver
pi         851   828  2 13:27 ?        00:00:00 /usr/local/bin/smartpireadout
root       872   834  0 13:27 ?        00:00:00 /usr/local/bin/smartpimodbusserver
pi         880   754  0 13:27 pts/0    00:00:00 grep --color=auto smartpi

Was ist denn hier los?

LG
Daniel

[frank]

Hallo Daniel,

die gleiche Beobachtung habe ich auch gemacht: https://forum.enerserve.eu/showthread.php?tid=1348
Meine Vermutung war, dass es daran liegt, dass die Prozesse mittels su mit anderen Benutzern gestartet werden. Leider gab es zu dem Beitrag bisher keine Rückmeldung.

Grüße
Frank

[daniel.pernold]

Hallo Frank,

danke, ich dachte "smartpi" sei eine binary, das ist aber ein Skript. Auweia.
Das Skript ist jedenfalls komplett kaputt, tut nicht was es soll. Ich hab's versucht zu reparieren.

/etc/systemd/system/smartpi.service

Code:

[Unit]
Description=SmartPi
After=syslog.target network.target remote-fs.target nss-lookup.target systemd-journald-dev-log.socket

[Service]
User=pi
Group=pi
Type=forking
ExecStart=/usr/local/bin/smartpi start
ExecStop=/usr/local/bin/smartpi stop
Restart=on-failure
StandardOutput=null
StandardError=null

[Install]
WantedBy=multi-user.target

/etc/systemd/system/smartpimodbus.service

Code:

[Unit]
Description=SmartPi ModbusServer
After=syslog.target network.target remote-fs.target nss-lookup.target systemd-journald-dev-log.socket

[Service]
Type=simple
ExecStart=/usr/local/bin/smartpimodbusserver
KillMode=process
RestartSec=5
Restart=on-failure
StandardOutput=null
StandardError=null

[Install]
WantedBy=multi-user.target

/usr/local/bin/smartpi

Code:

#!/bin/sh
### BEGIN INIT INFO
# Provides:          SmartPi
# Required-Start:
# Required-Stop:
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Kurze Beschreibung
# Description:       Längere Beschreibung
### END INIT INFO

echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device

# Actions
case "$1" in
   start)
       /sbin/ifconfig eth0:1 169.254.3.10 netmask 255.255.0.0 up
       # START
       /sbin/hwclock --hctosys
       /usr/local/bin/smartpireadout &
       /usr/local/bin/smartpiserver &
       /usr/local/bin/smartpi_check_umts.sh &
       ;;
   stop)
       /sbin/hwclock --systohc
       killall smartpiserver &
       killall smartpireadout &
       killall smartpi_check_umts.sh &
       ;;
   restart)
       # RESTART
       killall smartpiserver &
       killall smartpireadout &
       killall smartpi_check_umts.sh &
       sleep 1
       /usr/local/bin/smartpi_check_umts.sh &
       /usr/local/bin/smartpireadout &
       /usr/local/bin/smartpiserver &
       ;;
esac

exit 0

Danach ausführen:

Code:

$ sudo systemctl enable smartpimodbus.service
$ sudo service smartpimodbus start

Damit laufen die Prozesse mal sauber mit ihrem entsprechenden User. NodeRed habe ich rausgenommen, das gehört da nicht rein.
Keine Garantie auf Vollständigkeit, bitte gegenchecken und eventuell hier Verbesserungen posten.

@Jens: Bitte repariert das in euren Paketen.

LG
Daniel

[daniel.pernold]

Ich nochmal. Habe mir heute noch etwas Zeit genommen die einzelnen Dienste des SmartPi auch als eigenständige Systemd Services zu konfigurieren. Das Ganze sieht bei mir jetzt so aus:

Code:

pi@smartpi:~ $ ls -la /etc/systemd/system/smartpi*
lrwxrwxrwx 1 root root 51 Sep 30 14:22 /etc/systemd/system/smartpimodbus.service -> /usr/local/etc/systemd/system/smartpimodbus.service
lrwxrwxrwx 1 root root 52 Sep 30 14:22 /etc/systemd/system/smartpireadout.service -> /usr/local/etc/systemd/system/smartpireadout.service
lrwxrwxrwx 1 root root 51 Sep 30 14:22 /etc/systemd/system/smartpiserver.service -> /usr/local/etc/systemd/system/smartpiserver.service
lrwxrwxrwx 1 root root 45 Sep 30 14:31 /etc/systemd/system/smartpi.service -> /usr/local/etc/systemd/system/smartpi.service

Code:

pi@smartpi:~ $ cat /etc/systemd/system/smartpimodbus.service
[Unit]
Description=SmartPi ModbusServer
After=syslog.target network.target remote-fs.target nss-lookup.target systemd-journald-dev-log.socket

[Service]
Type=simple
ExecStart=/usr/local/bin/smartpimodbusserver
KillMode=process
RestartSec=5
Restart=on-failure
StandardOutput=null
StandardError=null

[Install]
WantedBy=multi-user.target

Code:

pi@smartpi:~ $ cat /etc/systemd/system/smartpireadout.service
[Unit]
Description=SmartPi Readout
After=syslog.target network.target remote-fs.target nss-lookup.target systemd-journald-dev-log.socket

[Service]
User=pi
Group=pi
Type=simple
ExecStart=/usr/local/bin/smartpireadout
KillMode=process
RestartSec=5
Restart=on-failure
StandardOutput=null
StandardError=null

[Install]
WantedBy=multi-user.target

Code:

pi@smartpi:~ $ cat /etc/systemd/system/smartpiserver.service
[Unit]
Description=SmartPi Server
After=syslog.target network.target remote-fs.target nss-lookup.target systemd-journald-dev-log.socket

[Service]
User=pi
Group=pi
Type=simple
ExecStart=/usr/local/bin/smartpiserver
KillMode=process
RestartSec=5
Restart=on-failure
StandardOutput=null
StandardError=null

[Install]
WantedBy=multi-user.target

Code:

pi@smartpi:~ $ cat /etc/systemd/system/smartpi.service
[Unit]
Description=SmartPi
After=syslog.target network.target remote-fs.target nss-lookup.target systemd-journald-dev-log.socket

[Service]
User=pi
Group=pi
Type=forking
ExecStart=/usr/local/bin/smartpi start
ExecStop=/usr/local/bin/smartpi stop
Restart=on-failure
StandardOutput=null
StandardError=null

[Install]
WantedBy=multi-user.target

Das smartpi-Skript in /usr/local/bin habe ich auf das Notwendigste abgespeckt. Da ich UMTS nicht verwende habe ich dort nur noch das mit dem i2c Adapter drinnen.  Man kann sich das vermutlich auch komplett sparen? Was meinst du Jens? Was tut das echo genau?

Code:

pi@smartpi:~ $ cat /usr/local/bin/smartpi
#!/bin/sh
### BEGIN INIT INFO
# Provides:          SmartPi
# Required-Start:
# Required-Stop:
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Kurze Beschreibung
# Description:       Längere Beschreibung
### END INIT INFO

echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device

exit 0

Die Prozessliste sieht jedenfalls nun no sehr sauber aus und es funktioniert auch alles wie gewohnt. Die einzelnen Services lassen sich nun bequem steuern, und vor allem, sie beenden auch sauber. :-)

Code:

pi@smartpi:~ $ ps -ef | grep smartpi
pi         537     1  1 14:24 ?        00:00:12 /usr/local/bin/smartpiserver
pi         540     1  1 14:24 ?        00:00:09 /usr/local/bin/smartpireadout
root       665     1  0 14:24 ?        00:00:01 /usr/local/bin/smartpimodbusserver

LG
Daniel

[daniel.pernold]

Ich hab' das Ganze jetzt noch verfeinert. Ich installiere ein Service namens "SmartPi Environment", alle anderen Services müssen das Environment ausführen lassen, bevor sie starten. Dort kann man nun alle Schandtaten hineinimplementieren, die man vor dem Starten der anderen Services benötigt. Dort habe ich das i2c reingepackt. Das smartpi.service ist nun obsoloet und kann mit sudo systemctl disable smartpi.service deaktiviert werden.

Code:

pi@smartpi:~ $ ls -la /etc/systemd/system/smartpi*
lrwxrwxrwx 1 root root  48 Sep 30 20:44 /etc/systemd/system/smartpienv.service -> /usr/local/etc/systemd/system/smartpienv.service
lrwxrwxrwx 1 root root  51 Sep 30 14:22 /etc/systemd/system/smartpimodbus.service -> /usr/local/etc/systemd/system/smartpimodbus.service
lrwxrwxrwx 1 root root  52 Sep 30 14:22 /etc/systemd/system/smartpireadout.service -> /usr/local/etc/systemd/system/smartpireadout.service
lrwxrwxrwx 1 root root  51 Sep 30 14:22 /etc/systemd/system/smartpiserver.service -> /usr/local/etc/systemd/system/smartpiserver.service

Code:

pi@smartpi:~ $ cat /etc/systemd/system/smartpienv.service
[Unit]
Description=SmartPi Environment
After=syslog.target network.target remote-fs.target nss-lookup.target systemd-journald-dev-log.socket

[Service]
Type=simple
ExecStart=echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device
KillMode=process
RestartSec=5
Restart=on-failure
StandardOutput=null
StandardError=null

[Install]
WantedBy=multi-user.target

Exemplarisch eines der SmartPi Services (man achte auf das After=smartpienv.service):

Code:

pi@smartpi:~ $ cat /etc/systemd/system/smartpireadout.service
[Unit]
Description=SmartPi Readout
After=smartpienv.service

[Service]
User=pi
Group=pi
Type=simple
ExecStart=/usr/local/bin/smartpireadout
KillMode=process
RestartSec=5
Restart=on-failure
StandardOutput=null
StandardError=null

[Install]
WantedBy=multi-user.target

Das "SmartPi Environment" Service muss man natürlich auch mit sudo systemctl enable smartpienv.service aktivieren.

LG
Daniel

[frank]

Hallo Daniel

schön gelöst, ich hoffe das findet Einzug ins Image bzw. ins Paket.

Die I2C-Sache ist IMHO für die integrierte RTC. Das müsste man inzwischen schöner mit einem Overlay in der config.txt lösen können.

Viele Grüße
Frank

[jens]

Hallo Daniel,

wir werden das für das nächste Image übernehmen.
Danke dafür :-)

Die Zeile:
ExecStart=echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device
ist für den integrierten RTC

Viele Grüße Jens

[frank]

Warum muss der smartpimodbusserver eigentlich mit root-Rechten laufen?

Grüße
Frank

[muennich]

Hallo Zusammen,

ich hab das aktuelle Image ... 2020-10-05_smartpi_buster.img ? ... heute in Betrieb genommen.
Selbst nach 1h Laufzeit reagiert das System sehr träge. Siehe daszu auch mein Beitrag auf Frank´s   Hohe Systemauslastung durch InfluxDB (enerserve.eu)
Bin ich der "Erste", der dieses Image in Betrieb nimmt? Wahrscheinlich nicht!

Was läuft da falsch?

Ich bitte um Unterstützung. Ich bin nur in Windows "zuhause". Unter Linux habe ich lediglich Einsteigerkenntnisse.

Danke
Gruß
Andreas

[muennich]

Hallo liebe Leut,

bitte um Hilfe.
Ich hab nun nochmal von vorne angefangen.

• 2020-10-05_smartpi_buster.img auf neue SD
  
• Rein in einen neuen rpi 3B+ (zuvor erfolgreich getestet mit 2021-01-11-raspios-buster-armhf-lite.img)
  
• rpi angeschlossen an LAN - das smartpi2.0-Modul, Dieses an L und N - Maus, Tastatur, HDMI
  
• startet zuerst normal.
  
• dann bleibt für ca. 15min der Bildschirm dunkel.
  
• Dann erscheint "zeilenweise" die Desktop-GUI ... nur mit dem Papierkorb (wirklich auf Deutsch!)... sonst nix. 
  
• Ich habe noch mal 1/2h gewartet ... keine Änderung
  
• Mauszeiger bewegbar ... über rechte Maustaste Kontextmenü mit "New Folder", "New File" ...
  
• Wenn auf das Papierkorbsymbol links geklickt wurde, dann verschwindet es (=> nix mehr am Desktop! ... nur noch das Standard-Hintergrundbild). => neues Kontextmenü bei Rechtsklick: "Terminal emulator ... Web browser ... Applications ... ObConf ... Reconfigure ... Restart ... Exit"
  
• Bei Auswahl von "Reconfigure" verschwindet das Kontextmenü und es bleibt ein leeres Hintergrundbild mit bewegbarem Mauszeiger ohne Reaktion auf die Maustasten. 
  

• Über SSH und IP-Adresse (aus Router und MAC-Adresse des Vorversuches mit rpi-Standard-Image bekannt!) kommt keine Verbindung zustande ... auch nicht nach mehr als einer Stunde.
  
• "PuTTY Fatal Error - Network error: Software caused connection abort"
  

• Bei http:\<IP-Adresse> kommt zuerst, ganz träge, die Web-GUI mit aberwitzigen Werten (die angeschlossenen Messwandler sind leer, kein Stromdurchfluss!). Nach erfolglosen Navigationversuchen im WebGUI-Menü kommt dann nur noch Textmeldung "500 Internal Server Error".
  

• => Nach 2h ohne Veränderung Stromunterbrechung mit Neustart aber nur zu Meldungs"flut" unter Anderm mit ext4-Fehlern bis zu "end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(172,2)"
  
• keine Verbindung über SSH oder gar http möglich!
  

Das rpi-Board schein unbeschadet, da mit der SD aus dem Grundfunktionstest des board (wieder "befreit" vom smartpi2.0-Modul und über die micro-USB-Buchse mit 5V-rpi-Standard-Netzteil versorgt) einwandfrei startet und läuft!

Ist das smartpi2.0-Modul eventuell defekt?

Gern kann ich für tiefere Analysen Bildschirmphotos nachliefern.

Danke für Unterstützung.