ubuntuusers.de

Zum Problem:

Ich starte in der Crontab von Root ein Shellscript

@reboot  sudo -u myuser /home/myuser/cronrun.sh & 

Das Shellscript soll unter meinem User laufen, dies funktioniert.

/home/myuser/cronrun.sh:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

#!/bin/bash
(
#sudo systemctl restart xrdp &  # wg. Fehler
sleep 10
/usr/local/bin/backrest &
sleep 10 && python3 /home/myuser/pvmonitor/pv-monitor-multisystem.py &
while true
 do 
  # shelly-Plug 
  #Pow r3
  curl -sS http://admin:osterbern@192.168.178.11/cm?cmnd=status%208| ts "[%d.%m.%y-%H.%M]" | xargs echo| /home/myuser/convhuhn.sh 
  /home/t759f/statistik/wr_schuppen_read.sh|ts "[%d.%m.%y-%H.%M]" | xargs echo|/home/t759f/statistik/convschuppen.sh
  curl http://192.168.178.10/?m=1 |ts "[%d.%m.%y-%H.%M]"| xargs echo >> /home/myuser/statistik/Stromverbrauch.txt
  /home/myuser/akkustatus1.sh &
  /home/myuser/akkustatus2.sh &
  /home/myuser/pv-power.sh &
  sudo /home/myuser/stromverbrauch.sh &
  sudo /home/myuser/wp-html.sh &
  /home/myuser/processmonitor.sh &
  /home/myuser/ssh-test.sh &
  sleep 300
done
) 2>&1 | tee /tmp/cronrun_error.out

sleep 10 && python3 /home/myuser/pvmonitor/pv-monitor-multisystem.py & endet kurz nach dem Start, ebenso cronrun.sh

Das ganze dient der Überwachung und Steuerung meiner Solaranlage mit Aufzeichnung von Statistiken.

Wenn ich /home/myuser/pvmonitor/pv-monitor-multisystem.py als User starte läuft es, ich möchte es aber nach dem Boot auf meinem Server automatisch laufen lassen. Das ganze ist auch schon sehr lange gelaufen, ich habe aber meine Anlage umgebaut, nun suche ich den Fehler.

Ich vermute einer der Background-Jobs stürzt ab und reisst alles zu Boden.

Die letzten Einträge von /tmp/cronrun_error.out

Code
01.02.2026 032 16:01:07  Batterieinverter set to  147 W
INFO:pvmonitor:write_loader Huawei0 set to 0
write_loader Huawei 0  set to  0 A
INFO:pvmonitor:write_loader Huawei1 set to 0
write_loader Huawei 1  set to  0 A

Zeigen das Prozessende nicht an.

Wie kann ich den Verursacher finden ?, kann man den Prozess /home/myuser/pvmonitor/pv-monitor-multisystem.py und /home/myuser/cronrun.sh tracen um die Ursache zu finden.

Ich komme aus dem Grossrechnerbereich, da würde ich die Accountingdaten durchsuchen, da steht dann drin wer wem auf die Mütze geschlagen hat.

Danke für eure Hilfe.

Vorweg: Du wirst Gründe haben, mit 26.04 ein unfertiges und für den produktiven Betrieb noch nicht freigegebenes Betriebssystem zu benutzen, aber klug ist das möglicherweise nicht.

franze_m schrieb:

[…] Ich starte in der Crontab von Root ein Shellscript

@reboot  sudo -u myuser /home/myuser/cronrun.sh & 

Das Shellscript soll unter meinem User laufen […]

Und das von root gestartete, aber als normaler Benutzer laufende Skript benutzt dann wieder sudo um Befehle als root auszuführen.

Wenn man einen Prozess als normaler Benutzer ausführen will, kann man dafür einfach die Crontab des Benutzers verwenden. In der Crontab des Benutzers root, und ebenso in der Crontab des Systems sollte man nur Prozesse starten, die als root laufen sollen und müssen.

Vorstehendes gilt, sofern man überhaupt den veralteten Cron benutzen will. Sinnvoller bei einem aktuellen Ubuntu-System wäre die Nutzung des dafür vorgesehenen Init-Dienstes systemd.

Sofern Du auf Cron bestehst: Es ist immer falsch, die Prozesse in der Crontab mit einem & zu beenden. Auch in Skripten ist das nur in seltenen Fällen sinnvoll. Und ebenso ist ein sudo in einer Crontab immer falsch, schon weil es kein Terminal gibt, über das man das Passwort eingeben kann.

Überdenke die Aufrufstruktur Deiner Skripte.

Zur Fehlersuche:

• Alles steht im Systemlog, was man mit journalctl durchsuchen kann.

• Cron schickt für jeden ausgeführten Job eine E-Mail an den Besitzer der jeweiligen Crontab. Damit das funktioniert, muss man allerdings ein E-Mail-System installieren, weil das inzwischen bei Linux nicht mehr Standard ist.

Hallo Kb, ich benutze Sudo in der Root Crontab, da nach dem Reboot meines Wissens nur Root etwas starten kann. Die Crontab des Users wird doch nur gestartet, wenn der User auch angeloggt ist oder liege ich da falsch ?

Ich habe das & aus der crontab entfernt, löst aber das Problem nicht.

1
2
3

myuser@localhost:~$ ps -ef|grep cronrun
myuser       4525    4511  0 18:14 pts/1    00:00:00 grep --color=auto cronrun
myuser@localhost:~$

myuser@localhost:~$ journalctl|grep cronrun
Feb 01 15:12:42 localhost.localdomain dbus-daemon[9277]: [session uid=1000 pid=9277] Activating via systemd: service name='ca.desrt.dconf' unit='dconf.service' requested by ':1.76' (uid=1000 pid=10083 comm="/usr/bin/mousepad /tmp/cronrun_error.out" label="unconfined")
Feb 01 16:01:41 localhost.localdomain dbus-daemon[3822]: [session uid=1000 pid=3822] Activating via systemd: service name='ca.desrt.dconf' unit='dconf.service' requested by ':1.76' (uid=1000 pid=4663 comm="/usr/bin/mousepad /tmp/cronrun_error.out" label="unconfined")
myuser@localhost:~$ 

Der Cronrun-Prozess ist verschunden, ich habe das System um 18 Uhr neu gestartet.

Ja, da liegst du falsch.

Ergänzung: es können sogar User Cronjobs starten, die sich aus Sicherheitsgründen gar nicht direkt anmelden können, weil sie kein Passwort haben.

franze_m schrieb:

ich benutze Sudo in der Root Crontab, da nach dem Reboot meines Wissens nur Root etwas starten kann.

Das ist falsch. Man kann manche Dienste auch mit z. B. einer user-service-unit (oder mit einem user-cronjob) starten. Z. B.:

CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/vino-server.service
             └─1108 /usr/libexec/vino-server

Die Crontab des Users wird doch nur gestartet, wenn der User auch angeloggt ist oder liege ich da falsch ?

Ja, du liegst falsch.

Ich habe nun den Crontabeintrag in den User verlegt. Danke für den Tipp.

Leider ändert das an meinem Problem nichts, das die cronrun.sh endet ohne eine Fehlermeldung. Mit journalctl kann ich nichts finden.

Gibt es noch eine Idee, wie ich nach dem Start des Systems meine Statistiken für die verschiedenen Systeme alle 5 Minuten erstellen kann ? Pro Statistik gibt es eine Programm. Ich wollte nicht alles in Crontab legen, da die Einträge evtl. nicht mitgesichert werden, da sie nicht in meinem Verzeichnisss liegen.

Interessant ist immer noch wer killt cronrun.sh ?

franze_m schrieb:

Interessant ...

BTW: Warum benutzt Du sudo in deinem Script. Wenn Du Teile/Dienste hast die unter root ausgeführt/laufen müssen, dann könntest Du für diese Teile /Dienste, ein Script/cronjob/etc. für root benutzen.

Ich benutze Sudo in meinen Scripten, damit ich die ganze Überwachung an einer Stelle in meinem User habe. Dies verhindert ein Chaos mit den Dateien und Einträgen. Wenn ich ein neues System erstelle oder ein Upgrade mache, habe ich alle Daten in meinem Verzeichniss und muss nur einen Eintrag zum Start in die Crontab schreiben. Das Sudo ist notwendig, damit ich auf Geräte oder Web-Verzeichnisse von meinen Statistiken zugreifen kann.

Es nutzt mir nichts, wenn die Daten und Einträge überall verteilt sind, da ist mir das Risiko zu gross das sie beim Backup vergessen werden.

franze_m schrieb:

Ich benutze Sudo in meinen Scripten, damit ich die ganze Überwachung an einer Stelle in meinem User habe. Dies verhindert ein Chaos mit den Dateien und Einträgen.

Naja, du wirst doch noch zwischen root und deinem user trennen bzw. unterscheiden können.

@franze_m Ich würde das schreiben des Fehlerprotokolls aus dem Skript rausnehmen was wohl abstürzt und in die crontab verschieben. Denn den Absturz von sich selbst wird das dann ja nicht mehr in die Protokolldatei schreiben können.

Wobei systemd statt crontab/@reboot auch eine Überlegung Wert ist. Auch da kann man die Ausgabe leicht protokollieren. Und bekommt auch beim Absturz die Information ob/welches Signal den Prozess beendet hat. Und man muss nicht immer neu booten beim testen wenn man das neu starten will.

root → sudo -u → sudo 🙄 Mir ist ganz schwindelig. Dazu ist ja schon etwas gesagt worden.

franze_m schrieb:

… Das ganze ist auch schon sehr lange gelaufen, ich habe aber meine Anlage umgebaut, nun suche ich den Fehler. …

Das Konstrukt hat zuvor funktioniert? Könnte es ein Seiteneffekt von dem sudo-rs sein? Vielleicht mal mit dem Alternativen-System auf sudo.ws wechseln.

Hallo Ruth, das ganze hat vorher funktioniert. Es läuft nun nachdem ich strace eingefügt habe um den Fehler zu finden.

1

@reboot strace -k -ff --trace=all -c -o /tmp/cronrun.txt /home/t759f/cronrun.sh

@reboot strace -k -ff --trace=all -c -o /tmp/cronrun.txt /home/t759f/cronrun.sh

Meine Sudoversion ist:

Sudo-Version 1.9.15p5
Sudoers-Policy-Plugin Version 1.9.15p5
sudoers-Dateigrammatik Version 50
Sudoers I/O plugin version 1.9.15p5
Sudoers audit plugin version 1.9.15p5

Irgendwie ist es komisch.

Hallo zusammen, ich habe das Problem mit systemd und

[Unit]
Description=cronreboot systemd service.

[Service]
Type=simple
User=t759f
Group=t759f
WorkingDirectory=/home/t759f
ExecStart=/home/t759f/cronrun.sh
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
RestartSec=5s
TimeoutStartSec=30s
Environment=NODE_ENV=production
#StandardOutput=file:/tmp/cronreboot_service.out
StandardError=file:/tmp/cronreboot_service.err
#StandardOutput=journal
#StandardError=journal

[Install]
WantedBy=multi-user.target[Unit]
Description=cronreboot systemd service.

[Service]
Type=simple
User=myuser
Group=myuser
WorkingDirectory=/home/myuser
ExecStart=/home/myuser/cronrun.sh
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
RestartSec=5s
TimeoutStartSec=30s
Environment=NODE_ENV=production
#StandardOutput=file:/tmp/cronreboot_service.out
StandardError=file:/tmp/cronreboot_service.err
#StandardOutput=journal
#StandardError=journal

[Install]
WantedBy=multi-user.target

gelöst.

Danke für die Tipps.