[gelöst zum 2.x] erinnerung zu bestimmtem datum

[michaa7]

Ich nutze keine kalenderfunktion und möchte (möglichst) nicht die nächste anwendung deshalb installieren müssen:

Gibt es eine möglichkeit sich mit linux boardmitteln lokal eine mail ***zu einem bestimmten datum*** an mich als user zu senden. Mailen per CLI geht ja mit mail(x), läßt sich das irgendwie an ein datum knüpfen?

Beispiel: Ich möchte am 05.01.2015 eine mail erhalten dass am nächsten tag <dies und jenes> stattfindet und ich nicht vergessen soll (will ) etwas bestimmtes zu erledigen.

Diese mail möchte ich eben heute beauftragen, aber erst am 05.01.2015 erhalten.

[rendegast]

In /etc/cron.daily/... unterbringen

Code: Alles auswählen

[ "x$(date +%F)" = "x2015-01-05" ] && /pfad/mailscript.sh
exit 0

Entsprechend verfeinern resp. in persönliche crontab.



Oder in der persönlichen crontab den cron-Mail-Mechanismus benutzen

Code: Alles auswählen

... [ "x$(date +%F)" = "x2015-01-05" ] && echo "nachricht, erinnerung"
exit 0

[michaa7]

In /etc/cron.daily/... unterbringen

Code: Alles auswählen

[ "x$(date +%F)" = "x2015-01-05" ] && /pfad/mailscript.sh
exit 0

Entsprechend verfeinern resp. in persönliche crontab.



Oder in der persönlichen crontab den cron-Mail-Mechanismus benutzen

Code: Alles auswählen

... [ "x$(date +%F)" = "x2015-01-05" ] && echo "nachricht, erinnerung"
exit 0

1. Danke
2. erste hälfte des ersten vorschlags hört sich nach root an, in soweit vermute ich dass die persönliche crontab dem zweck angemessener ist. Aber ganz klar ist mir nach lesen von "man crontab" nicht geworden was der cron-Mail-Mechanismus ist und wie ich das konfiguriere. ich habe crontab noch nie benutzt, schaue jetzt erstmal ob ich es schaffe morgen ein testnachricht zu erhalten, dann sehen wir weiter ...


EDIT:
Was ich überhaupt nicht verstehe ist wie dein command mit der crantab syntax zusammenpaßt. Ist das was du in die crontab schreibst? Kommt mir irgendwie nicht so vor, schon allein weil das crontab format kein jahr kennt.

* * 5 1 * sollte aber 05.01. bedeuten

Ich versteh's nicht ... , noch weniger deinen exitcode, da ist doch bash, oder?

EDIT2:

Dieser eintrag in meine pers. crontab

* * 19 12 * echo "test nachricht, erinnerung"

schickt mir eben jede minute eine mailerinnerung.

Ich hoffe nun, dass

0 12 19 12 * echo "test2 nachricht, erinnerung"

mir heute *nur um 12:00* eine mailerinnerung schickt, mal schaun ...

[Meillo]

Ich denke, mein Wiedervorlage-Script `wv' bietet genau das was du suchst:
http://marmaro.de/lue/txt/2013-05-07.txt

Man sollte in dem Code noch eine Kleinigkeit korrigieren: Fuege zu Beginn ein `cd' ein um ins Homeverzeichnis zu wechseln. Man bekommt naemlich Probleme wenn man den at-Aufruf aus einem Verzeichnis startet, das beim Ausfuehren dann nicht mehr existiert.

Zudem kann man den Ausfuehrungszeitpunkt auch davor ausgeben.

Eine aktuellere Version, die diese Verbesserungen beinhaltet, findet ihr hier:
http://marmaro.de/prog/various/wv

[rendegast]

Nunja, Syntax in einen cron-Job der pers. crontab, cron.d/ oder cron.daily/ sind natürlich unterschiedlich.
Hier ging es darum, daß ein täglicher Job sich selbst auf das richtige Datum testet,
um dann die entsprechende Aktion auszuführen.

Der cron-mail-Mechanismus:
Produziert ein Job Output, so generiert cron eine Mail.

Mit dem 'exit 0' wollte ich darauf hinaus,
daß der Test bei "falschem" Datum ja negativ ausgeht, cron dann aber dennoch keine Mail erzeugen soll.

In meiner crontab

Code: Alles auswählen

* * * * * false
* * * * * xxxxxx

Das zweite generiert eine Mail, aber wohl nicht wegen des Fehlers bei der Ausführung,
sondern wegen des Output "file not found".
Daher braucht es wohl kein 'exit 0' für den Fall eines fehlerhaften Testausgangs.
Es müste "nur" sichergestellt sein, daß unerwünschte Ausgabe nach /dev/null geht.

Ich habe hier ja auch nur cron.daily/man-db, welches ein solches 'exit 0' benutzt.
Das oder ein ':' findet eher bei den init.d/-Skripten Anwendung.
Habe in der Beziehung wohl etwas durcheinandergeworfen, Sorry.



Allgemein ist mir der mögliche resp. nicht mögliche Syntax in einer crontab-Zeile suspekt,
daher rufe ich meist einfach nur ein Skript auf, daß dann entsprechende Tests und Aktionen beinhaltet.

[Meillo]

Ich wundere mich nun doch so sehr, dass ich nochmal posten muss: Warum wird in diesem Thread denn ueber cron gesprochen? Cron ist doch fuer wiederkehrende Aufgaben da. Gesucht ist aber eine einmalige Erinnerung zu einem bestimmten Zeitpunkt.

Gibt es eine möglichkeit sich mit linux boardmitteln lokal eine mail ***zu einem bestimmten datum*** an mich als user zu senden.

Beispiel: Ich möchte am 05.01.2015 eine mail erhalten [...]

Diese mail möchte ich eben heute beauftragen, aber erst am 05.01.2015 erhalten.

Das ist ganz klar das Aufgabengebiet von at, nicht das von cron.

at - execute commands at a later time

[rendegast]

Warum wird in diesem Thread denn ueber cron gesprochen?

Ich mag at nicht, und cron ist immer da.

... und möchte (möglichst) nicht die nächste anwendung deshalb installieren müssen:

Gesucht ist aber eine einmalige Erinnerung zu einem bestimmten Zeitpunkt.

dazu ja der Test auf das Datum, in pers. crontab:

Code: Alles auswählen

1 1 * * * /pfad/notify.sh 2014-01-05

/pfad/notify.sh in der Art:

Code: Alles auswählen

#!/bin/sh

MARK="$1"
CURR="$(date +%F)"
[ "x$DATE" = "x$MARK" ] && echo "erinnerung $MARK"

[michaa7]

also, erstmal danke an euch beide, wieder ein bisschen was gelernt. Vor allem auch weil ich jetzt crontab in seinen grundzügen kennengelernt und ansatzweise verstanden habe. Eben auch mal nachgeschaut, at ist nicht installiert (Debian/sid(uction)), und crontab löst eben mein problem, auch wenn dieses programm eigentlich für wiederkehrende aufgaben gedacht ist. Aber einmal pro jahr ist ok, und ein mal pro jahr nachschauen ob es crontab leichen gibt ist auch ok.

Soweit ich das gestern und eben heute getestet habe ist die lösung recht einfach, crontab ist jetzt ja für mich als user eingerichtet, ein "crontab -e" bringt meine crontab in meinem standardeditor auf den schirm, dieser einzeiler diente mir gestern zum testen der grundfunktion

Code: Alles auswählen

* * 19 12 * echo "test nachricht, erinnerung"

indem es mir jede minute die nachricht "test nachricht, erinnerung" zumailte.

Diese änderung

Code: Alles auswählen

0 12 19 12 * echo "test2 nachricht, erinnerung"

sendete mit dann heute 2 sekunden nach 12:00 die entsprechende nachricht, so dass ich zuversichtlich davon ausgehe, dass diese beiden einträge ebenso funktionieren werden:

Code: Alles auswählen

0 17 5 1 * echo "morgen plimplamplum"
0 12 6 1 * echo "heute plimplamplum 16:00-18:00"

Alles in allem recht einfach zu handhaben.

Für längere nachrichten oder komplexere kommandos eignen sich möglicherweise eure scripte besser, aber für mein problem reicht wohl der einfache eintrag in die crontab ohne scriptaufruf. Wobei at in soweit interessant klingt als es nicht an ein datum gebunden ist sondern wohl sowas wie "in zwei wochen wieder" erlaubt. Behalt ich mal im visier.

[michaa7]

0 17 5 1 * echo "morgen plimplamplum"

hat heute nicht geklappt, ich bekam keine erinnerungsmail, warum?

Der rechner lief um genau 17:00 *nicht*, ich kam erst später heim. Nur sollte dann nicht anachron dafür sorgen, dass das nachgeholt wird? Und falls cron mit UTC rechnet hätte die mail um 18:00 eintrudelsn müssen, tat sie auch nicht.

Warum also habe ich keine mail erhalten?

[rendegast]

Ups,
anacron ist ja nur für die (wiederkehrenden) Einträge in /etc/anacrontab.
Hat mit den persönlichen crontabs oder den /etc/cron.d/ dann doch nichts zu tun.

Da wäre dann so ein (regelmäßig ausgeführtes) Skript nötig,
daß einmal die Nötigkeit der Ausführung prüft.
Andererseits ob der Job schon erledigt wurde, vielleicht anhand eines job.lock
(ähnlich anacrons /var/spool/anacron/).


Benutzer-anacrontabs sind so wohl nicht vorgesehen, es gibt kein Programm 'anacrontab'.
Also doch at?

[michaa7]

... Da wäre dann so ein (regelmäßig ausgeführtes) Skript nötig,
daß einmal die Nötigkeit der Ausführung prüft.
Andererseits ob der Job schon erledigt wurde, vielleicht anhand eines job.lock
(ähnlich anacrons /var/spool/anacron/).

Eine derartige erweiterung wäre für crontab wirklich wünschenswert.

Benutzer-anacrontabs sind so wohl nicht vorgesehen, es gibt kein Programm 'anacrontab'.
Also doch at?

Tja, da bin ich nun gespannt wie lange ich brauche bis ich da wieder durchblicke ..., werd' ich nun mal tun.

Danke für die aufklärung.

EDIT://
Ich befürchte auch at hilft nicht weiter:

At allows fairly complex time specifications, extending the POSIX.2 standard. It accepts times of the form HH:MM to run
a job at a specific time of day. (If that time is already past, the next day is assumed.)...

Mir scheint dass hier bei at wie bei crontab die zugrunde liegende philosophie immer laufende rechner (wie eben sienerzeit mainframes) voraussetzt, an temporär laufende PCs hat damals wohl niemand gedacht. Ich hatte wohl zu unrecht gehofft, dass anachron ein allheilmittel für zeitbasierte ausführung wäre.
Mal abgesehen davon, dass mir dies einen bugreport wert sein wird (nur nicht heute) stehe ichnun vor der frage: Wie kann ich auf einfache art auf meinen PC eine erinnerung hinterlegen, die eben auch dann noch abgeschickt wird, wenn der rechner erst nach dem festgelegten zeitpunkt wieder gebootet wird. Ich höre schon leute "kalender, kalender" rufen, ich wollt ' halt ne mail. Jetzt wird es wohl doch wieder eon post-it an der pinwand. [seufz]

[Meillo]

EDIT://
Ich befürchte auch at hilft nicht weiter:

At allows fairly complex time specifications, extending the POSIX.2 standard. It accepts times of the form HH:MM to run
a job at a specific time of day. (If that time is already past, the next day is assumed.)...

Es koennte sein, dass du das falsch verstehst. Dieser Fall tritt vielleicht nur auf, wenn du eine Uhrzeit ohne Datum eingibst. Sobald du ein Datum eingibst, dann kann diese Verschiebung wohl gar nicht passieren. Insofern waere das dann keine Disqualifikation.

Leider kann ich das alles gerade nicht ausprobieren. Laut Webrecherche koennte es sein, dass `atd' auch mit Downtimes zurecht kommt, da er nicht nur ausfuehrt was auf die jeweilige Minute gescheduled ist sondern alles was in der Vergangenheit liegt. Das ist moeglich, da, im Gegensatz zu Cron, jeder Job nur genau einmal abgearbeitet werden muss und dann geloescht wird. Ob die konkreten Implementierungen das so machen, weiss ich leider nicht. Vielleicht unterscheiden sich die Implementierungen auch. Ich meine mich zu erinnern, dass manche at-Implementierungen einfach auf cron aufsetzen ... damit haetten sie dann wohl das gleiche Problem.

Mir scheint dass hier bei at wie bei crontab die zugrunde liegende philosophie immer laufende rechner (wie eben sienerzeit mainframes) voraussetzt, an temporär laufende PCs hat damals wohl niemand gedacht.

Genau, denn die gab's damals noch nicht. Das ist aus meiner Sicht aber keine Philosophiefrage sondern eine Realitaetsfrage. Warum haette man sich mit dem komplizierten Problem der Downtime-Behandlung auseinandersetzen sollen, wo das in der Realitaet quasi nicht auftrat? Noch abwegiger wird die Frage, wenn man bedenkt, dass Unix grossteils ein Worse-is-better verkoerpert. (Okay, es ist schon eine Philosophiefrage, insofern, dass man entweder alle momentanen und zukuenftigen Moeglichkeiten abzudecken versucht oder nur das abdeckt was momentan noetig ist.)

... nur hilft dir das halt alles nichts.


Du koenntest dir nochmal at anschauen. Vielleicht fuehrt der vergangene Events ja doch aus.

[michaa7]

ok, danke mache ich. Melde mich dann nochmals.

[rendegast]

Läßt sich ja nachstellen mit

Code: Alles auswählen

qemu -rtc base=XXXX-XX-XX ...

In der VM sollte dabei kein ntp-Client laufen.

[michaa7]

ok, danke mache ich. Melde mich dann nochmals.

So, vom prinzip her funktioniert das wie es soll, zumindest sendet at den "output from your job" als mail an den user auch wenn der job in der vergangenheit lag weil der rechner zur angegebenen zeit nicht lief.

Wie man das textlich noch verbessern kann wird ggf. thema eines anderen thread sein ...

Danke an alle.

[Meillo]

Wie man das textlich noch verbessern kann wird ggf. thema eines anderen thread sein ...

Ich verweise nochmal auf mein `wv'-Script, das ich oben erwaehnt habe.