crontab -e -u user1 wird ignoriert...

[Doc.Mc.Fly]

Hallo,

ich hab da mal ne Frage zu dem cron -Dienst.

Wenn ich

Code: Alles auswählen

crontab -e

verwende funktioniert alles prima. Alle Skripte und Befehle werden ausgeführt. (benutze ich seit Jahren)

Hingegen wenn ich aber crontab für einen anderen User verwende

Code: Alles auswählen

crontab -e -u user1 

funktioniert einfach nichts.
Ich hab auch die Zeilen vom User1 in die root-crontab kopiert... funktioniert prima.

Es sieht so aus, als würde crontab für User1 vollständig ignoriert werden. Auch MAILTO ist gesetzt. Keine Mail.

Auch habe ich mit

Code: Alles auswählen

crontab -r - u User1

die Tabelle gelöscht und nochmal neu angelegt... Nada...

Auch etwas banales wie

Code: Alles auswählen

*/1 * * * * /bin/echo "test" > /home/User1/crontest.txt

funktioniert nicht.

Kann mir jemand einen Tipp geben, was für Voraussetzungen existieren müssen, damit crontab auch für andere Nutzer funktioniert.

Danke für hilfreiche Postings...
Clemens

[TomL]

Code: Alles auswählen

su User1
crontab -e

[Doc.Mc.Fly]

Hallo Thomas,

Danke... habs gleich mal ausprobiert...

Code: Alles auswählen

su User1
crontab -e

ist scheinbar identisch mit

Code: Alles auswählen

crontab -e -u User1

Ich lade in der gleichen crontab mit dem gleichen echo-Aufruf...

und passieren tut nix...

Gruß Clemens

[TomL]

ist scheinbar identisch mit

Nein ist es nicht...

Diese vier Varianten sollten alle funktionieren:

Code: Alles auswählen

# crontab -e -u User1

Code: Alles auswählen

$ sudo crontab -e -u User1

Code: Alles auswählen

$ su User1
$ crontab -e 

Code: Alles auswählen

$ su -
# crontab -e -u User1

Nur unter Debian ist der normale User nicht per default sudo-autorisiert... was für das Arbeiten unter Debian auch nicht notwendig ist.... insofern ist Variante 2 nur ein theoretisches Beispiel.

[Doc.Mc.Fly]

Hi Thomas,

vielleicht habe ich mein Problem nicht richtig beschrieben... bei beiden Varianten:

Code: Alles auswählen

crontab -e -u User1 

oder

Code: Alles auswählen

su User1 
crontab -e 

lande in der gleichen Crontab-Datei. Beides mal speichere ich ab und beides mal steht folgendes in der Datei:

Code: Alles auswählen

*/1 * * * * /bin/echo "hallo"   /home/User1/echo.test.txt

und jedes mal passiert: NICHTS!

und ich bin auf der Suche warum nichts passiert...

Gruß Clemens

[TomL]

Bei mir gehts auf diese Weise:

Code: Alles auswählen

# crontab -e -u User1
no crontab for User1 - using an empty one
crontab: installing new crontab

# cat /var/spool/cron/crontabs/User1
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# :::
# For more information see the manual pages of crontab(5) and cron(8)
# 
# m h  dom mon dow   command
*/1 * * * * /bin/echo "$(date)"  >>/home/User1/echo.test.txt

Nach einigen Minuten:

Code: Alles auswählen

# cat /home/User1/echo.test.txt
Mo 10. Jun 19:03:01 CEST 2019
Mo 10. Jun 19:04:01 CEST 2019
Mo 10. Jun 19:05:01 CEST 2019
Mo 10. Jun 19:06:01 CEST 2019
Mo 10. Jun 19:07:01 CEST 2019
Mo 10. Jun 19:08:01 CEST 2019

Noch etwas später im Journal:

Code: Alles auswählen

# journalctl -b | grep "(User1) CMD"
Jun 10 19:03:01 thomaspc CRON[5990]: (User1) CMD (/bin/echo "$(date)"  >>/home/User1/echo.test.txt)
Jun 10 19:04:01 thomaspc CRON[5996]: (User1) CMD (/bin/echo "$(date)"  >>/home/User1/echo.test.txt)
Jun 10 19:05:01 thomaspc CRON[6014]: (User1) CMD (/bin/echo "$(date)"  >>/home/User1/echo.test.txt)
Jun 10 19:06:01 thomaspc CRON[6040]: (User1) CMD (/bin/echo "$(date)"  >>/home/User1/echo.test.txt)
Jun 10 19:07:01 thomaspc CRON[6060]: (User1) CMD (/bin/echo "$(date)"  >>/home/User1/echo.test.txt)
Jun 10 19:08:01 thomaspc CRON[6065]: (User1) CMD (/bin/echo "$(date)"  >>/home/User1/echo.test.txt)
Jun 10 19:09:02 thomaspc CRON[6072]: (User1) CMD (/bin/echo "$(date)"  >>/home/User1/echo.test.txt)
Jun 10 19:10:01 thomaspc CRON[6079]: (User1) CMD (/bin/echo "$(date)"  >>/home/User1/echo.test.txt)
Jun 10 19:11:01 thomaspc CRON[6084]: (User1) CMD (/bin/echo "$(date)"  >>/home/User1/echo.test.txt)
Jun 10 19:12:01 thomaspc CRON[6094]: (User1) CMD (/bin/echo "$(date)"  >>/home/User1/echo.test.txt)

vielleicht habe ich mein Problem nicht richtig beschrieben...

Ja, das stimmt. Du solltest bei der Problembeschreibung nicht die Verschleierung von Umständen in den Vordergrund stellen.... das macht es nur unnötig kompliziert, das eigentliche Problem zu identifizieren. Vergleich mal die Vollständigkeit meiner Statements und die Ausgaben. Man erkennt eindeutig: Wer (hier root), Womit (der Befehl), Wie (Syntax)... hat zu welchem Ergebnis (wo, was,vollständig) geführt. Das ist aus Deinen Angaben nicht zu lesen... man muss also umständlich rumraten und verplempert damit nur seine Zeit.

[Doc.Mc.Fly]

Hi Thomas,

Das mit dem journalctl ist nen guter Tipp. Das unterstreicht was ich so seltsam finde. Denn das journalctl spukt nur aus, dass die Tabelle geändert wurde, aber nicht dass es etwas tut...

Nicht mal ne Fehlermeldung...

Code: Alles auswählen

# journalctl -b | grep "(User1)"
...
Jun 10 21:04:31 host-167 crontab[21784]: (User1) END EDIT (User1)
Jun 10 21:06:26 host-167 crontab[24141]: (root) BEGIN EDIT (User1)
Jun 10 21:07:42 host-167 crontab[24141]: (root) REPLACE (User1)
Jun 10 21:07:42 host-167 crontab[24141]: (root) END EDIT (User1)
Jun 10 21:08:01 host-167 cron[18094]: (User1) RELOAD (crontabs/User1)
Jun 10 21:10:16 host-167 crontab[24321]: (root) BEGIN EDIT (User1)
Jun 10 21:10:24 host-167 crontab[24321]: (root) REPLACE (User1)
Jun 10 21:10:24 host-167 crontab[24321]: (root) END EDIT (User1)
Jun 10 21:11:01 host-167 cron[18094]: (User1) RELOAD (crontabs/User1)

Gruß Clemens

[getphp]

@Doc.Mc.Fly

Keine Sorge, deine Problembeschreibung ist gut verständlich.

Schau mal, ob dein user1 cronjobs ausführen darf. Da gibt es mindestens diese beiden Möglichkeiten:

1. Gibt es eine Datei mit dem Namen /etc/cron.allow ?
Wenn ja, dürfen nur die dort eingetragen User Cronjobs ausführen. (Ein user pro Zeile)

2. Gibt es eine Datei /etc/cron.deny ?
Wenn user1 dort drin steht, darf er keine Cronjobs ausführen.

Wenn das nicht zur Lösung beigetragen hat: was passiert, wenn du als root diesen Befehl ausführst?

Code: Alles auswählen

crontab -u user1 -l

und als Gegenprobe noch mal als user1 nur

Code: Alles auswählen

crontab -l

Gibt es einen Unterschied?

[Doc.Mc.Fly]

Hallo zusammen,

vielen Dank Thomas und getphp (guter Nick .

Der letzte Tipp von getphp hat mich auf die cron.allow und cron.deny Doku gebracht. -> das war's scheinbar nicht.
Anschließend bin ich über

Code: Alles auswählen

/etc/security/access.conf

gestolpert. -> das änderte aber auch nix....

aber ich dem Zusammenhang bin ich über

Code: Alles auswählen

tail -f /var/log/syslog |grep cron

gestossen.

aahhh.. dort steht immer "Authentication failure".

und dann bin ich über duckduckgo ganz schnell auf die Lösung gekommen. User1 hatte keinen /etc/shadow - EIntrag.

Jetzt gehts...

Also noch mal Danke...
Clemens

[getphp]

Spannend - wie schön, dass es eine Lösung gibt

[TomL]

Wenn der User bisher noch gar nicht angelegt war, hätte man das mit vollständigen Infos gesehen, denn dann wäre der "su" schon fehlgeschlagen. War der User allerdings angelegt, nur ohne Password, hat dieser fehlende Eintrag in der Shadow jedenfalls definitiv nix damit zu tun, dass der Cron-Job nicht ausgeführt wurde. Man kann problemlos einen User ohne Password anlegen, für den ebenso problemlos trotzdem die Cron-Jobs ausgeführt werden.

Code: Alles auswählen

# cat /etc/shadow | grep hannes
hannes:*:18058:0:99999:7:::
root@dell-e6320:~

# cat /home/hannes/echo.test.txt
Di 11. Jun 16:54:01 CEST 2019
Di 11. Jun 16:55:01 CEST 2019
Di 11. Jun 16:56:01 CEST 2019
Di 11. Jun 16:57:01 CEST 2019
Di 11. Jun 16:58:01 CEST 2019
Di 11. Jun 16:59:01 CEST 2019

Natürlich kann man auch einen User mit einem exotischen (oder auch ganz ohne) Homedir anlegen... dann muss natürlich der Echo-Befehl im Cronjob auf jeden Fall fehlschlagen, aber das wären Infos, die dann ebenfalls gefehlt haben. Offensichtlich ist meine Glaskugel wohl der geplanten Obsoleszenz zum Opfer gefallen und orakelt nur noch Blödsinn... denn die kam jedenfalls damit nicht klar... ein Hilfsmittel, was anscheinend andere ganz offensichtlich gar nicht brauchen und die mit einer Problembeschreibung ohne Angaben trotzdem bestens klarkommen.

Btw:
tail+rsyslog ist keine Lösung, oder bestenfalls die schlechtere.... weil rsyslog als eigenständiger Nachrichtensammler seit 4 Jahren tot ist. Soll heissen, rsyslog bekommt nur noch einen Abklatsch von systemd-journald . Vollständige Infos stehen also im Journal. Statt

Code: Alles auswählen

tail -f /var/log/syslog |grep cron

wäre (vollständig, um zu erkennen, mit welchen Rechten es ausgeführt wird)

Code: Alles auswählen

# journalctl -f | grep -i cron

eindeutig die bessere Variante

[jph]

Mal aus dem Originalpost zitiert:

Hingegen wenn ich aber crontab für einen anderen User verwende

Code: Alles auswählen

crontab -e -u user1 

funktioniert einfach nichts.
Ich hab auch die Zeilen vom User1 in die root-crontab kopiert... funktioniert prima.
…

Im ersten Befehl schreibst du user1 durchgehend klein, in allen nachfolgenden Stellen User1 mit großem U. Sofern das keine Platzhalter sind: user1 ist ein anderes Konto als User1!

[Doc.Mc.Fly]

Hallo zusammen,

damit habe ich nicht gerechnet, dass ich, jetzt wo ich die Lösung gefunden habe, noch Postings bekomme

@Thomas:
Danke für Deine Tipp mit dem Journal. Ich verwende das Debian seit Woody (immer mal upgegradet oder installiert und die Einstellungen kopiert). An das systemd habe ich mich noch nicht so richtig gewöhnt.

Ich bin auch Dir für Deine Hilfe, dankbar, aber Dein Stil ist IMHO unhöflich. Wenn ich Dir nicht genug Informationen liefere (oder Du die Details überliest), dann bitte einfach mich, die Informationen zu liefern. Mir vorzuwerfen, dass ich nicht alles liefere und behauptest, dass ich Du hellsehen musst, ist äußerst beleidigend, denn dieses habe ich nie von Dir verlangt. Ich könnte genauso schreiben, dass ich eine Glaskugel brauche, um herauszufinden, welche Informationen Du benötigst, um das Problem zu verstehen bzw. zu lösen.

@jhp:
Danke für Dein wachsames Auge. User1 ist/war nur ein Platzhalter. Beim Ersetzen war ich wohl nicht konsequent genug.

@all:
Hier noch ein paar technische Details zu meinem Problem in Nachgang:

Ohne Shadow-Eintrag:

Code: Alles auswählen

# su User1 
su: Authentication failure
(Ignored)
User1 # 

Sprich ich kann als root in User1 wechseln und als User1 agieren. Bspw. Skrite ausführen, die darauf bestehen, dass diese nicht als root ausgeführt werden.

Darüber ist auch scheinbar crond gestolpert. Da ich aber in der Konsole trotz der Fehlermeldung: "Authentication failure" weiterarbeiten konnte, hatte ich in dem Moment nicht gedacht, dass crond damit ein Problem hat. Auch dass crond mich über diese "Authentication failure" nicht via E-Mail informierte, hat mich verwundert. (Darum war ich in diesem Forum gelandet)

Wenn ich aber einen shadow-Eintrag (ohne Passwort-Hash) hinzufüge, dann sieht es auf der Konsole so aus:

Code: Alles auswählen

# su User1 
User1 # 

Dann geht der cron auch.

Die Webseite: https://blog.unikorn.me/quickfix-cron-a ... ilure.html hat mich die Lösung gebracht.

Herzliche Grüße
Clemens

[TomL]

Ich bin auch Dir für Deine Hilfe, dankbar, aber Dein Stil ist IMHO unhöflich.

Das ist das, was Du vielleicht herauslesen möchtest, was aber nichts mit meinen Absichten zu tun hat. Ich bin einfach nur sachlich gestimmt, beschränke mich auf (mir) verfügbare Fakten und interessiere mich auschließĺich für das Problem und die Lösung. Ich befasse mich also ausschließlich mit technischen Aspekten... egal, wer das wann und warum beschrieben hat. Irgendwas drumherum oder dahinter interessiert mich dabei meistens nicht, deswegen bin ich auch nicht unhöflich gegen eine Person... weil das bei der Lösung des Problems sowieso nicht hilft. Und wenn fehlende Informationen die Lösung erschweren, dann sag ich das als simple Feststellung auch.... gerade auch aus der Erfahrung heraus, dass nicht wenige Problembeschreiber häufig sowieso anonyme Daten noch mal mit Sternchen und unnötiger Zurückhaltung von Informationen (Devise: bloß nix preisgeben, ich bin hochgeheim) völlig sinnlos weiter anonymisieren und damit nicht selten die Lösungsfindung einfach nur sinnlos erschweren.

Wenn Du Dich beleidigt fühlst, nehme ich das zur Kenntnis und entschuldige mich dafür. Ich habe allerdings jetzt eine technische Vorsorge getroffen, womit eine Wiederholung künftig ausgeschlossen ist.

[Doc.Mc.Fly]

Hallo Thomas,

ich kann das anonymisieren gut verstehen, wenn es sich beispielsweise, um einen Server handelt, der im Netz erreichbar ist. Dann vielleicht veröffentlicht man da eine Lücke (ohne es zu Wissen), die vielleicht nicht jetzt, aber später für unsaubere Zeitgenossen interessant ist.

Deine Vermutung:

Devise: bloß nix preisgeben, alles hochgeheim

ist also kein Faktum sondern Deine persönlich Interpretation deiner Erfahrungen. Und auch hier zeichnet sich Deine unhöfliche Art der Formulierungen ab, denn auch hier unterstellst Du dem Fragesteller übermäßig geheimhaltendes Verhalten. IMHO sind Sicherheitsbedenken und Datensparsamkeit heutzutage ein hohes Gut.

Und hätte es Dir geholfen, das Problem einzugrenzen, wenn ich statt "User1" den richtigen Namen "clo-sbg1-00" genannt hätte?

Hier im Forum sind die Fragesteller in vielen Fällen keine Vollprofis (denn das liegt in der Natur der Sache dieses Forums). Sich aber darüber zu beschweren, dass diese zu wenig Informationen hier posten, ist unprofessionell. Ein Profi kann den Fragesteller aufklären, welche Infos er benötigt, um das Problem einzugrenzen, dass wäre ein gutes Verhalten im Support.

Ich arbeite ua. im technischen Support und bekomme immer wieder Anfragen mit zu viel, zu wenig oder falschen Informationen. Na und? Dann rede ich mit denen, erkläre was ich brauche, um ihnen helfen zu können.

Mit freundlichem Gruß
Clemens