staging.inyokaproject.org

Hallo,

ich würde gerne Signal Desktop alle 10 Tage automatisch starten.

Nach dieser Anleitung könnte ich die Datei ~/.anacron/etc/anacrontab folgendermaßen gestalten:

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

10 300 signal-cron nice STARTE /usr/share/applications/signal-desktop.desktop

Ich weiß jetzt nur nicht, was ich für STARTE einsetzen muss. Ich würde gerne die Desktop-Datei zum Start nutzen, da dort alles Wichtige für Signal drin konfiguriert ist.

In ~/.profile müsste dann noch folgendes:

/usr/sbin/anacron -t /home/user/.anacron/etc/anacrontab -S /home/user/.anacron/spool &> /home/user/.anacron/anacron.log

Da ja in anacrontab eine Shell definiert ist, recht evtl. auch:

anacron -t ~/.anacron/etc/anacrontab -S ~/.anacron/spool &> ~/.anacron/anacron.log

Könnte das so funktionieren?
Würde das den Job auch wie gewünscht starten, wenn ich den Rechner über Nacht in Bereitschaft ruhen lasse, denn beim Aufwecken würde ich ja keinen normalen Login machen?

Hm, ich sehe da zwei Probleme: Erstens, wenn der Rechner in Bereitschaft ist, werden keine Cronjobs ausgeführt, würde ich mal behaupten.

Zweitens, kannst Du per Cron keine GUI-Programme starten.

Schau Dir vielleicht mal https://kofler.info/systemd-timer-als-cron-alternative/ . Vielleicht können die GUI-Programme starten. Das weiß ich nicht.

Hallo,

systemd Timer Units können in der Tat nachträglich ausgeführt werden, wenn der Rechner zum Zeitpunkt der eigentlich Ausführung nicht lief. systemd Units sind aber grundsätzlich auch nicht dazu gemacht, mit GUI Programmen zu interagieren.

Gruß, noisefloor

UlfZibis schrieb:

[…]

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

10 300 signal-cron nice STARTE /usr/share/applications/signal-desktop.desktop

Ich weiß jetzt nur nicht, was ich für STARTE einsetzen muss.

Da das ja ein Argument für signal-cron sein soll, musst Du natürlich erst einmal erklären, was das für ein Programm ist, wo es herkommt (jedenfalls kein Standard bei Ubuntu) und wo/wie es dokumentiert ist. Mit anacron/cron selbst hat es nichts zu tun.

kB schrieb:

Mit anacron/cron selbst hat es nichts zu tun.

Das ist im um die Ecke verstandenen Sinn wohl richtig, weil frei wählbar, doch Manpages lesen kann helfen, die wirkliche Bedeutung zu ergründen:

The job-identifier can contain any non-blank character, except slashes. It is used to identify the job in Anacron messages, and as the name for the job's timestamp file.

Doc_Symbiosis schrieb:

Hm, ich sehe da zwei Probleme: Erstens, wenn der Rechner in Bereitschaft ist, werden keine Cronjobs ausgeführt, würde ich mal behaupten.

Zweitens, kannst Du per Cron keine GUI-Programme starten.

Na irgendwie muss es ja wohl gehen, eine GUI Timer-gesteuert zu starten, erstens auch bei "Verpassen" des Zeitpunkts wegen "Rechner schläft", und zweitens weil eine solche hier fast täglich aufpoppt, die grafische "Aktualisierungsverwaltung".

Und kann mir denn keiner sagen. wie man mittels *.desktop-Datei das damit gemeinte GUI-Programm starten kann, mal ganz ohne die Überlegungen zur Timer-Steuerung?

noisefloor schrieb:

systemd Timer Units können in der Tat nachträglich ausgeführt werden, wenn der Rechner zum Zeitpunkt der eigentlich Ausführung nicht lief. systemd Units sind aber grundsätzlich auch nicht dazu gemacht, mit GUI Programmen zu interagieren.

Aber sie können in einer User-Session ausgeführt werden. Vielleicht geht da doch was.

UlfZibis schrieb:

Und kann mir denn keiner sagen. wie man mittels *.desktop-Datei das damit gemeinte GUI-Programm starten kann, mal ganz ohne die Überlegungen zur Timer-Steuerung?

Das geht mittels gtk-launch: https://manpages.ubuntu.com/manpages/focal/man1/gtk-launch.1.html

seahawk1986 schrieb:

Das geht mittels gtk-launch: https://manpages.ubuntu.com/manpages/focal/man1/gtk-launch.1.html

Suppi, danke Dir. Dann kann ich ja jetzt mal anfangen, mit dem Timer-Klapperatismus zu experimentieren.

Ich habe nun in ~/.anacron/etc/anacrontab :

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

1 10 signal-cron nice gtk-launch signal-desktop

und in ~/.profile :

anacron -t ~/.anacron/etc/anacrontab -S ~/.anacron/spool &> ~/.anacron/anacron.log

Dann habe ich das ganze mit bash .profile gestartet. In der Systemüberwachung konnte ich dann sehen, dass da der Job anacron als User läuft. Nach 10 Minuten poppte dann die Signal Desktop auf. Wunderbar, der Teil funktioniert dann schon mal.

Gleichzeitig verschwand dann der anacron-Job aber auch. Daraus schließe ich nun, dass dann morgen, wenn ich den Rechner wieder aus der Bereitschaft aufwecke, dann leider doch nichts passiert, denn ~/.profile wird ja nur bei einem echten Session-Start ausgeführt. Wie schade, so funktioniert es also nicht wirklich.

Hat jemand eine Idee, wie ich anacron bei jedem Aufwachen aus der Bereitschaft starten kann, oder wie ich erreichen kann, dass anacron auch nach erstmaligem Erledigen seiner Aufgabe dauerhaft am Laufen bleibt?

Wie wäre es mit folgender Logik: Per Unit oder /etc/crontab wird bei Rechnerstart ein Skript gestartet. Dieses enthält eine Dauerschleife, welche alle x Minuten

• Die Existenz der Datei /usr/local/signaldesktop_letzter_start prüft.

• Ist sie nicht vorhanden, wird sie erzeugt und per gtk-launch Signal gestartet.

• Ist sie vorhanden, wird per stat der Zeitstempel geprüft.

• Ist er < 10 Tage, nichts machen.

• Ist er > 10 Tage, wird per touch ein neuer Zeitstempel gesetzt und Signal gestartet.

Falls das Skript nach Schlafenlegen/Aufwachen nicht sauber weiterlaufen sollte und quasi abgeschossen und neu gestartet werden muss, hilft dieser Post weiter.

Edit:

Das muss wohl alles in deinem Benutzerkontext ablaufen. Dann also keine Systempfade / Systemunit etc. nehmen, sondern beispielsweise das Prüfskript in deinen Autostart legen.

dingsbums schrieb:

Wie wäre es mit folgender Logik: Per Unit oder /etc/crontab wird bei Rechnerstart ein Skript gestartet. Dieses enthält eine Dauerschleife, welche alle x Minuten

Das ist eine schöne Idee, doch genauso macht das anacron, wenn ich es richtig verstanden habe. Also warum "das Rad neu erfinden". Das Problem ist, dass dies alles unter root läuft, und von da aus eine Brücke zur User-Session geschaffen werden muss.

Falls das Skript nach Schlafenlegen/Aufwachen nicht sauber weiterlaufen sollte und quasi abgeschossen und neu gestartet werden muss, hilft dieser Post weiter.

Das schaue ich mir morgen mal an.

Das muss wohl alles in deinem Benutzerkontext ablaufen. Dann also keine Systempfade / Systemunit etc. nehmen, sondern beispielsweise das Prüfskript in deinen Autostart legen.

Hm, der Autostart startet doch nur einmal.

Ich hätte echt nicht gedacht, dass so eine kleine Aufgabe so kompliziert ist. Schade, dass es keine kleine GUI-Anwendung gibt, womit man solche Dinge konfigurieren kann.

Würde es auf solch einfache Art machen:

10 Tage Prüfung.

find /Pfad/Datei -mtime +9 -exec <Anw./Kommando> \;

ich würde gerne Signal Desktop alle 10 Tage automatisch starten.

Also Datei zur Prüfung mit anlegen und dann erneuern lassen.

(.sh) in Autostart oder per Schleife laufen lassen.(etwa Prüfung aller X Minuten)

Ich würde einen Systemd-Timer für eine Systemd-Unit in der User Session laufen lassen. Da kann man auch vorgeben, dass verpasste Zeitpunkte nachgeholt werden sollen.

Generell muss man halt dran denken, dass es auch nicht-grafische Sessions geben kann und dass einem Dinge wie Screen Locking usw. einen Strich durch die Rechnung machen können - kannst du das Szenario etwas genauer beschreiben, das erfordert, dass das Programm alle 10 Tage automatisch gestartet wird? Eventuell finden sich da ja noch bessere Ansatzpunkte.

Die crontab ist auch nicht gedacht, um grafische Programme zu starten, aber es geht, wenn man grafisch eingeloggt ist und XDG_RUNTIME_DIR benutzt (zumindest mit Xubuntu):

1

10 19 * * 2,3,4,5	XDG_RUNTIME_DIR=/run/user/1000 notify-send -u critical "Erinnerung"

Das gibt mir an den Tagen Di, Mi, Do, Fr um 19:10 eine notify-send Notiz aus, aber der Rechner läuft auch durch und ist permanent im Grafikmodus.

Die Variablen, die man setzen muss, haben sich aber alle 5 Jahre geändert, mal war es DISPLAY, das man setzen musste, dann musste man zusätzlich mit XAUTHORITY hantieren, jetzt ist es XDG_RUNTIME_DIR, bei Wayland wird es wohl auch wieder anders werden.

Auch den Transfer zu anacron könnte ich jetzt nicht aus dem Stehgreif bewältigen.