Cronjob Problem - /bin/sh: 1: root: not found

[loltest]

Hallo,

habe Nullmailer für den Logversand via SMTP installiert und sitze nun gerade an der Konfiguration. Der Versand von Testmails funktioniert soweit, beim versenden der Logs hapert es momentan noch aber nun bin ich bei der Fehlersuche auf ein neues Problem gestoßen:

Code: Alles auswählen

root@domain.de

Received: (nullmailer pid 5288 invoked by uid 0);
	Sun, 21 Feb 2016 21:39:01 -0000
To: root@domain.de
Subject: cron for user root root   [ -x /usr/lib/php5/sessionclean ] && /usr/lib/php5/sessionclean
Date: Sun, 21 Feb 2016 16:39:01 -0500
Message-Id: <1456090741.288421.5287.nullmailer@hostname>
From: <root@domain.de>

/bin/sh: 1: root: not found

Der betreffende Cronjob für php5 setzt sich folgendermaßen zusammen:

Code: Alles auswählen

# Look for and purge old sessions every 30 minutes
09,39 *     * * *     root   [ -x /usr/lib/php5/sessionclean ] && /usr/lib/php5/sessionclean

Der Cronjob wurde automatisch mit der Installation von php56 (dotdeb) angelegt, habe nichts verändert. Wie kommt es zu o.g. Fehlerausgabe?


Grüße und vielen Dank im voraus!

[4A4B]

Steht der Cronjob in einer Datei unterhalb /etc oder in der User-Crontab von root ('crontab -l')? wenn letzteres, dann ist die User-Angabe 'root' in der Cronjob-Zeile überflüssig, was dann auch zu solch einer Fehlermeldung führen würde

[loltest]

Hallo,

der Cronjob befindet sich in /etc/cron.d/php5. crontab -l enthält bis jetzt keinerlei Einträge.


Gruß

[heisenberg]

Der Fehler tritt offensichtlich deswegen auf, da cron das Wort "root" als auszuführenden Befehl interpretiert. Die crontab ist aber richtig.

Der Unterschied zwischen dem cronjob in /etc/cron.d/php5-sessionclean und einem cronjob eines Benutzers ( z. B. root) ist dass bei letzterem kein Benutzername eingetragen ist. D. h. die Benutzer-crontab ist um ein Feld kürzer.

Insgesamt wundert mich das ganze, da die php5-sessionclean ok ist und korrekt ausgeführt werden müsste. Bei mir gibt es exakt den gleichen Cron-Job und der wird korrekt ausgeführt.

Du könntest mal in die cron-Manpage schauen, ob da irgendwas dazu steht. Gibt's da vielleicht eine Änderung, dass das 6. Feld nicht mehr der Benutzername ist? Du könntest auch testweise mal schauen, ob der Fehler nicht mehr auftritt, falls Du das Wort "root" entfernst, auch wenn dass eigentlich keine korrekte Syntax mehr ist.

[loltest]

Habe das Problem nun mit deiner Hilfe lösen können.

Kurz erläutert:

Ich nutze eine abgespeckte wheezy Installation auf einem VPS mit nur 128 MB RAM. Zwecks Speicheroptimierung habe ich einige Pakete gegen Alternativpakete mit geringerem Footprint ausgetauscht, so auch das mitgelieferte cron mit dcron (dillon's lightweight cron daemon), was wohl (offenbar?) die Angabe eines Benutzernamens innerhalb der Cron-Syntax nicht zu unterstützen scheint. Nach dem Entfernen von 'root' wird der Cronjob nun ganz normal ausgeführt.

Danke für den Lösungsansatz.

[mistersixt]

Ich bin immer wieder erstaunt, welche Probleme so ans Tageslicht kommen... und was die Ursachen dafür sind. Wird nicht langweilig hier im Forum !

[loltest]

Ja, schon etwas blöd von mir, dass ich hier nicht direkt einen Zusammenhang erkannt habe. Ein genaueres unter die Lupe nehmen von dcron oder zumindest die Reinstallation vom ursprünglichen cron wäre unabhängig von der eigentlichen Lösung auf jeden Fall naheliegend gewesen, alleine zum eingrenzen der Fehlerquelle.

Bin wohl davon ausgegangen, dass die Syntax von Cron ungleich von verwendeten Paketen einem Standard unterliegt. Würde mich auch durchaus als PC Veteran auf diversen Gebieten bezeichnen, aber was Linux-Server und das ganze drumherum mit der Shellsyntax usw. angeht bin ich eben noch ein echter DAU .

[uname]

Wäre vor allem schön gewesen, wenn du von "dcron" geschrieben hättest. Ich wusste nicht mal dass es sowas gibt. Ok ich würde auch niemals auf die Idee kommen so eine wichtige Komponente aus einer Fremdquelle zu beziehen. Wie viel KB hast du denn eingespart?

Schau dir lieber mal folgende Ausgabe an:

Code: Alles auswählen

dpkg-query --show --showformat='${Installed-Size} ${Package}\n'| sort -nr |more

[TRex]

Das liefert aber auch Pakete mit Status c. Die würde ich zwar (nur) aufräumen wollen, verfälschen aber in dem Kontext das Ergebnis.

[loltest]

Mir geht es hierbei weniger um die Größe (die paar GB die ich zur Verfügung habe sind für meine Zwecke so großzügig dimensioniert, dass ich mir um Einsparungen im KB-Bereich auf jeden Fall keine Gedanken machen muss) als vielmehr um den RAM-Footprint der Pakete im Betrieb, speziell bei einem Daemon wie cron der ständig im Hintergrund aktiv ist. Am Bespiel von dcron sieht das dann folgendermaßen aus:

Code: Alles auswählen

# ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
   root      1586       0.0        0.4    1956    664 ?            Ss      11:45       0:00   /usr/sbin/crond

# free -m
                 total       used       free     shared    buffers     cached
Mem:         128          47         80             0             0            43
-/+ buffers/cache:        3       124
Swap:        192            0       192

cron:

Code: Alles auswählen

# ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
   root      1670       0.0        0.7    2192    872 ?            Ss      11:47       0:00   /usr/sbin/cron

# free -m
                 total       used       free     shared    buffers     cached
Mem:         128          48         79             0             0            44
-/+ buffers/cache:        3       124
Swap:        192            0       192

Eine Absenkung des Speicherbedarfs von weniger als einem MB hört sich jetzt natürlich erst mal nicht sonderlich viel an, allerdings sind das auch nur Idle-Werte, beim Ausführen von Cronjobs peakt es dann noch mal ein bisschen. Primär geht es hier darum den Gesamtspeicherbedarf des Systems durch viele kleinere Optimierungen effektiv zu senken. Durch das Austauschen einiger Pakete und ein paar tweaks am Webserver, PHP und MySQL lassen sich hier durchaus Einsparungen im Bereich von 2x-3x MB erzielen was bei einem Server mit 128+64 MB vSwap sicher nicht ganz ohne ist. Der freigewordene Speicher kann dann als Cache für PHP o.ä. genutzt werden.

Wenn man einen Server mit Speicherwerten jenseits von 1 GB+ betreibt wird man derartige Optimierungsversuche natürlich eher belächeln, allerdings ist das auch nicht der Punkt. Wichtig war mir, das System so ressourcenschonend wie möglich zu betreiben.