[gelöst] Crontab als angemeldeter Benutzer ausführen

[joe2017]

Hallo zusammen,

ist es möglich einen Crontab immer als angemeldeten Benutzer auszuführen ohne das dieser für jeden Benutzer spezifisch angelegt wird?

Ich möchte jede Stunde ein Script ausführen, welches mit dem angemeldeten User ausgeführt wird.
Ich habe gehofft man könnte dies in der Datei /etc/crontab mit $USER einstellen. Jedoch funktioniert das nicht.

Wenn ich folgendes ausführe passiert gar nichts.
sudo nano /etc/crontab

Code: Alles auswählen

* *     * * *    $USER    /path/script.sh

[MSfree]

ist es möglich einen Crontab immer als angemeldeten Benutzer auszuführen ohne das dieser für jeden Benutzer spezifisch angelegt wird?

Nein, dafür ist cron auch nicht gedacht. cron führt Aufträge in regelmässigen Abständen aus, ggfls. auch mit Benutzerrechten, ob der Benutzer aber eingelogt ist oder nicht, spielt für cron keine Rolle.

[joe2017]

Und mit was könnte ich ein Script in regelmäßigen Abständen für den angemeldeten Benutzer ausführen?
Gibt es hierfür eine andere Lösung?

[TomL]

Ich möchte jede Stunde ein Script ausführen, welches mit dem angemeldeten User ausgeführt wird.

Das wird wohl nur über einen Umweg gehen. Vom root-Crontab wird stündlich das Script gestartet. Das Script ermittelt den angemeldeten User und wechselt dann den User-Context via pkexec für einen fork des Scriptes. Der fork läuft dann unter der UID des angemeldeten Users, der root-Main-Prozess kann sich dann beenden.

[joe2017]

Na das hört sich doch gar nicht schlecht an. Das werde ich mir am Montag gleich mal anschauen.
Evtl komm ich noch mal auf dich zu wenn ich hier nicht weiter komme.

Dank dir für den Tipp!

[TomL]

Schau Dir auch noch 'ne Alternative an... über pam.d->common-session kannst Du direkt beim Login des Users ein Script unter der UID des Users starten. Das kann sich ja direkt in den Hintergrund wegforken und sich dann stündlich (sleep 3600) aktivieren. Man muss dann nur noch den Logout des Users kommunizieren.

[joe2017]

Das hatte ich auch erst als Idee. Jedoch wäre das Script dann die ganze Zeit im Hintergrund offen.
Das ist ehr unschön. Wenn die andere Geschichte sauber funktioniert wäre das vielleicht die bessere Alternative.

[TomL]

Das ist ehr unschön

Ja... mit welcher technischen Begründung?

[joe2017]

Findest du nicht, dass ein Cron der immer wieder gestartet wird sauberer ist, als ein Script was im Hintergrund mit einem sleep läuft?
Wenn z.b das Script aus irgendeinem Grund crashen würde, wäre der cron im Vorteil weil er immer wieder gestartet wird.

Ist jetzt meine Meinung. Einfach aus dem Bauch heraus.

[DeletedUserReAsG]

Bau dir doch ’nen Cronjob, der als Root läuft und zu den gewünschten Zeiten ein Script startet, welches schaut, welcher User gerade angemeldet ist, und das betreffende Script mit dieser UID startet.

[Livingston]

Wie wär's denn mit ner eigenen Crontab pro User? Erstellen lässt sich die aus dem User-Login heraus mit

Code: Alles auswählen

crontab -e

oder als root mit

Code: Alles auswählen

crontab -e -u <USER>

Die Tabelle wird von dem Programm crontab dann in /var/spool/cron/crontabs/<USER> deponiert.
Im eigenen Cronjob könnte dann überprüft werden, ob der User eingeloggt ist.

[joe2017]

Bau dir doch ’nen Cronjob, der als Root läuft und zu den gewünschten Zeiten ein Script startet, welches schaut, welcher User gerade angemeldet ist, und das betreffende Script mit dieser UID startet.

Genau das hatte mir ja TomL vorgeschlagen. Das werde ich mir am Montag mal genauer ansehen.
Falls jemand zufällig ein solches Script im Einsatz hat, und mir sagt wie ich das genau mache muss ich mir nicht alles selbst zusammensuchen.
Andernfalls schaue ich mir das Montag selber an.

Schönes Wochenende zusammen.

[MSfree]

Vom root-Crontab wird stündlich das Script gestartet....

Ich halte das für keine gute Idee, zumal, und das hatte ich oben schon geschrieben, cron nicht dafür gedacht ist. Ich bitte hierbei zu bedenken, daß Linux ein Multiusersystem ist, also mehrere Benutzer gleichzeitig angemeldet sein können, oder ein Benutzer mehrfach angemeldet sein kann. Bei meinem Rechner sehe ich z.B. gerade folgendes:

Code: Alles auswählen

benutzer@rechner [/home/benutzer] : w
 14:43:13 up 2hours, 6 users,  load average: 0,33, 0,18, 0,08
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
benutzer    tty7     :0               14:38    4:59   7.21s  0.02s /bin/sh /usr/bin/startkde
benutzer    pts/0    :0               14:39    0.00s  0.00s  0.00s w
benutzer    pts/1    :0               14:39    4:13   0.00s  0.00s -bash
benutzer    pts/2    :0               14:39    4:13   0.00s  0.00s -bash
benutzer    pts/4    :0               14:39    4:13   0.00s  0.42s kded5 [kdeinit5]                                      
benutzer    pts/3    :0               14:39    4:13   0.00s  0.00s -bash

Ich bin also 6 mal eingelogt.

Daraus ergibt sich, daß ein Root-Conjob, der nach angemeldeten Usern fahndet, hier berücksichtigen muß, daß x Benutzer jeweils y-mal angemeldet sein können. Das kann, wenn man doppelt angemeldete Benutzer nicht berücksichtigt, zu mehrfachem ausführen von Skripten führen, mit teilweise ungewollten Ergebnissen.

Startet man pro Login so etwas, hat man ebenfalls das Problem, daß Skripte teilweise doppelt und überschneidend laufen.

Ich verstehe hier ehrlich gesagt auch nicht, warum so ein Geheimnis daraus gemacht wird, was joe2017 eigentlich damit bezwecken will. In 99% aller Fälle gibt es für sein (unbekanntes) Problem einfachere, bessere Lösungen.

[TomL]

Ich halte das für keine gute Idee, zumal, und das hatte ich oben schon geschrieben, cron nicht dafür gedacht ist. Ich bitte hierbei zu bedenken, daß Linux ein Multiusersystem ist, also mehrere Benutzer gleichzeitig angemeldet sein können, oder ein Benutzer mehrfach angemeldet sein kann.

Tja, ich gehe dem entgegengesetzt davon aus, das auf einem Enduser- oder Client-PC üblicherweise nicht gleichzeitig mehrere User angemeldet sind. Insofern wird der stündliche root-Crontab-Job vor diesem Hintergrund auch immer nur einen angemeldenten User ermitteln. Bei mir sieht das beispielsweise wie folgt aus:

Code: Alles auswählen

$ w
 15:11:55 up  5:15,  1 user,  load average: 1,50, 1,36, 1,30
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
thomas   tty7     :0               09:57    5:15m  5:59   4.51s /usr/bin/openbox

Was unsere Systeme angeht, trifft dieser Sachverhalt auf alle zu.... meiner Einschätzung nach bleibt das also konfliktfrei.

Ich verstehe hier ehrlich gesagt auch nicht, warum so ein Geheimnis daraus gemacht wird, was joe2017 eigentlich damit bezwecken will. In 99% aller Fälle gibt es für sein (unbekanntes) Problem einfachere, bessere Lösungen.

Das ist das größere Problem... aber leider auch ein sich immer wieder wiederholender Vorgang, das Fragen vom Informationsgehalt völlig unzureichend gestellt werden. Deshalb habe ich mich irgendwann dazu entschlossen, nicht mehr Energie in die Antwort zu investieren, als vorher in die Frage investiert wurde.

[jph]

Und mit was könnte ich ein Script in regelmäßigen Abständen für den angemeldeten Benutzer ausführen?
Gibt es hierfür eine andere Lösung?

Du könntest für diesen User einen Timer in der systemd-User-Instanz anlegen, die beim Einloggen automatisch gestartet wird.

[JTH]

Du könntest für diesen User einen Timer in der systemd-User-Instanz anlegen, die beim Einloggen automatisch gestartet wird.

Das würd ich hier auch vorschlagen. Unter /etc/systemd/user/foobar.{service,timer} abgelegt und einmal aktiviert, gilt das ganze systemweit für alle Benutzer. So ein Timer wird ohne manuellen Extraaufwand pro Benutzer garantiert nur einmal ausgeführt, auch wenn der mehrfach gleichzeitig angemeldet ist.

Grobes Grundgerüst:

Code: Alles auswählen

$ cat /etc/systemd/unit/foobar.service
[Unit]
Description=Foobar service

[Service]
Type=oneshot
ExecStart=/bin/echo Foobar

$ cat /etc/systemd/user/foobar.timer
[Unit]
Description=Foobar timer

[Timer]
OnCalendar=hourly

[Install]
WantedBy=timers.target

# systemctl --global enable foobar.timer

Falls der Timer für Root nicht ausgeführt werden sollte:

Code: Alles auswählen

# systemctl --user mask foobar.timer

[jph]

Du könntest für diesen User einen Timer in der systemd-User-Instanz anlegen, die beim Einloggen automatisch gestartet wird.

Das würd ich hier auch vorschlagen. Unter /etc/systemd/user/foobar.{service,timer} abgelegt und einmal aktiviert, gilt das ganze systemweit für alle Benutzer. So ein Timer wird ohne manuellen Extraaufwand pro Benutzer garantiert nur einmal ausgeführt, auch wenn der mehrfach gleichzeitig angemeldet ist.

Vereinfachungsvorschlag: wenn der Timer nur für einen User ausgeführt werden soll, dann kann man die Datei auch einfach in eines der in man 5 systemd.unit genannten Unterverzeichnisse im Home-Verzeichnis dieses Users legen.

[JTH]

Vereinfachungsvorschlag: wenn der Timer nur für einen User ausgeführt werden soll, dann kann man die Datei auch einfach in eines der in man 5 systemd.unit genannten Unterverzeichnisse im Home-Verzeichnis dieses Users legen.

Hier war ja nach einem Ansatz gefragt, der nicht für jeden Benutzer einzeln angelegt werden muss:

ist es möglich einen Crontab immer als angemeldeten Benutzer auszuführen ohne das dieser für jeden Benutzer spezifisch angelegt wird?

[joe2017]

Hallo zusammen,

da habt ihr natürlich Recht. Es wäre einfacher gewesen wenn ich euch mitgeteilt hätte was genau ich vorhabe. Jedoch dachte ich, dass es sinnvoller wäre wenn ich das allgemein halte und nicht spezifisch für einen einzelnen Fall Frage. So etwas kann man sicherlich auch in einem anderen Anwendungsfall benötigen.

Hier jedoch meine aktuelle Idee zu meiner Frage.
Ich hab das Problem, dass ich meine Benutzer über Ihre NFS Quota informieren möchte. Hierzu habe ich ein Script geschrieben welches die zur Verfügung stehende Quota mit dem aktuell verwendeten Speicher abgleicht. Dieses Script muss natürlich unter dem aktuell angemeldeten User in regelmäßigen Abständen ausgeführt werden. Falls jetzt die Idee der E-Mail Notification kommt. Das funktioniert leider nicht, da nicht jeder meiner Anwender über eine E-Mail Adresse verfügt.

Jetzt sind hier natürlich viele verschiedene Ansätze genannt worden. Ich werde mir das Ganze morgen genauer anschauen und prüfen was die beste alternative hierfür ist.
Falls noch jemand eine Idee hierzu hat wäre ich selbstverständlich sehr dankbar.

Guten Start in die Woche.

[inne]

Ähm Cron sendet doch aber auch eine E-Mail. Hier müsstet wohl das Setup angepasst werden damit auch Mails an lokale User gesendet werden können?! Im Grunde ist ein Username dann eine valide E-Mail-Adresse und wer eine externe hat, kann diese in die .forward eintragen.

Erkläre doch mal wie Du Quotas eingerichtet hast, denn ich kenne nur Linux File System Quotas (Aber stimmt, hier wird nur Root benachrichtigt)...

¢

[JTH]

Falls noch jemand eine Idee hierzu hat wäre ich selbstverständlich sehr dankbar.

Das hängt dann nochmal davon ab, wie du konkret die Benachrichtigung der Benutzer lösen willst, wenn nicht per Mail Per notify-send?

Nur für das regelmäßige Ausführen des Skripts wirst du mit den erwähnten Systemd-Timern vermutlich den wenigsten Aufwand haben.

[MSfree]

Ich hab das Problem, dass ich meine Benutzer über Ihre NFS Quota informieren möchte. Hierzu habe ich ein Script geschrieben welches die zur Verfügung stehende Quota mit dem aktuell verwendeten Speicher abgleicht. Dieses Script muss natürlich unter dem aktuell angemeldeten User in regelmäßigen Abständen ausgeführt werden.

Deine Benutzer melden sich an einem Clientrechner an, der von einem NFS-Server Massenspeicher mountet, der mit Quota limitiert ist.

Nur der Server weiß, wieviel Platz ein bestimmter Benutzer belegt hat und wieviel er noch zu Verfügung hat. Also muß das Skript auch auf dem Server laufen.

Der Server hat aber absolut keine Ahnung davon, daß sich ein Benutzer an einem Client angemeldet hat. Der Client teilt das dem Server auch nie mit. Selbst das Mounten des Massenspeichers ist letzlich zustandslos und nicht an einen bestimmten Benutzer gebunden.

Nur der Client weiß, wann sich welcher Benutzer eingelogt hat. Ein auf dem Client laufendes Skript, wie auch immer mehr oder weniger regel,ässig gestartet, bringt dir aber keine Informationen darüber, was auf dem Server abgeht.

Deine ausgeklügelte Vorgehensweise wird so also nicht funktionieren können.

Ich halte es auch für bedenklich, deine Benutzer regelmässig damit zu nerven, ihnen mitzuteilen, wieviel Platz ihnen noch auf dem Server zur Verfügung steht.

Der Server hat bereits Mechanismen, der eine Aktion auslöst, wenn ein Benutzer einen bestimmten Grenzwert erreicht, z.B. wenn 80% seines Quota erreicht sind. Dann schickt er völlig selbstständig eine Email an Benutzer und an root. Damit läßt man die Benutzer zwar gewissenmassen ins "offene Messer" laufen. Das ganze wird aber dadurch abgemildert, daß man die Benachrichtigung nicht erst abschickt, wenn es zu spät ist, sondern bei erreichen des Softlimits. Der Benutzer kann dann zumindest seine aktuelle Arbeit noch speichern, muß aber sofort danach aufräumen.

Eine regelmässige Benachrichtigung ist also einierseits gar nicht nötig und ggfls. sogar für alle die nervend, die nie ans Limit kommen. Zum anderen ist es gar nicht möglich, den Loginvorgang am Client dem Server mitzuteilen, so daß dieser dann irgendwelche Aktionen ausführt. (OK, es ist nicht ganz unmöglich, aber technisch aufwendig, da über das Netzwerk kommuniziert werden muß, wer was macht, ohne daß es dafür Standardtools gäbe).

[joe2017]

Also noch mal ganz kurz zur Erklärung.

Ich habe einen Debian NFS Server mit einer Partition für meine /home/users Ordner. Diese sind für jeden Benutzer mit Quotas beschränkt.
Meine User melden sich an meinen Clients an, welche einen Mountpint zu dem NFS Server haben /home/users

Somit ist das Home Verzeichnis für jeden User auf meinem Server.
Mein User Quotas auf meinem Server lege ich mit einem Script an. Hierzu habe ich eine kleine Config Datei in welcher lediglich die Informationen User,SoftLimit,HardLimit stehen. Diese werden via Script gesetzt und zusätzlich zwei versteckte Dateien (.softlimit, .hardlimit) in dem jeweiligen User Verzeichnis (/home/users/$USER/) abgelegt. Somit kann ich auf dem User schon einmal mein SoftLimit/HardLimit auslesen.

Jetzt kommt mein Client Script zum Einsatz, welches den Belegten Speicher von meinem Profil überprüft und dies mit den Quotas abgleicht. Mein Script gibt wie richtig vermutet mittels notify-send dem Benutzer eine entsprechende Information aus. Das habe ich auch bereits alles getestet und es funktioniert einwandfrei. Lediglich die Sache mit dem Script unter dem angemeldeten Benutzer bringt mich zum Verzweifeln.

[joe2017]

Also ich habe jetzt mal ein Service mit dem Timer unter /etc/systemd/user/ eingerichtet.

Zum Test habe ich den Timer auf 1min gestellt. Der Timer führt meinen Service aus, welcher mein Script ausführt.
In dem Script habe ich testweise ein echo &USER > /path/testfile eingetragen.

Das Script wird wie erwartet mittels Timer und Service jede Minute ausgeführt. Jedoch wird in der Datei kein Username eingetragen. Es wird jede Minute eine weitere Leere Zeile hinzugefügt.
Ich befürchte somit, das mein Script nicht unter dem aktuell angemeldeten User ausgeführt wird. Woran könnte das noch liegen?
Anbei meine Files:
Service

Code: Alles auswählen

[unit]
Description=notify-send Quota Service

[Service]
ExecStart=/path/bash_notify-send_quota.sh

[Install]
WantedBy=multi-user.target

Timer

Code: Alles auswählen

[unit]
Description=notify-send Quota Timer

[Timer]
OnBootSec=0min
OnCalendar=*:0/1
Unit=bash_notify-send_quota.service

[Install]
WantedBy=multi-user.target

Script

Code: Alles auswählen

echo $USER >> /path/testfile

Ich habe auch noch folgendes durchgeführt

Code: Alles auswählen

systemctl --user --global enable /etc/systemd/user/bash_notify-send_quota.service

[JTH]

Code: Alles auswählen

[Install]
WantedBy=multi-user.target

Das lass mal beim Service weg, du willst ja den Timer benutzen um den Service zu starten. Der Service selbst soll nicht durch Abhängigkeiten beim Boot gestartet werden.

Deshalb ist das

Ich habe auch noch folgendes durchgeführt

Code: Alles auswählen

systemctl --user --global enable /etc/systemd/user/bash_notify-send_quota.service

vermutlich kontraproduktiv, womöglich deine Fehlerquelle hier.

Beim Timer sollte laut Doku ein

Code: Alles auswählen

[Install]
WantedBy=timers.target

stehen – außer man weiß was man tut, wenn man dort anderes hinschreibt

Die Environment enthält ansich schon USER und anderes, evtl. wurde der Timer hier einfach falsch gestartet.