Subject: cron verstehen
Date: Thu, 08 May 2008 03:08:22 +0200
Ich habe bereits die manpages zu cron und crontab gelesen. Soweit
verstehe ich wie cron bedient wird.
Allerdings verstehe ich nicht warum(!) cron so bedient wird.
Also ich versuche cron zu verstehen und welche Designentscheidungen bzw
Konzepte dahinterstehen.
Mein größtes Unverständnis besteht darin, dass die jeweiligen
crontab-files mit bzw über die Anwendung crontab editiert werden müssen,
anstatt einfach die crontab-files direkt mit einem editor (vi, emacs,
etc) zu editieren.
Warum ist das so? Welches Prinzip steckt dahinter?
Warum gibt es crontab-files in /var/spool/* ? Was hat dieser Teil des
Verzeichnisbaums damit zu tun? Die crontab-files könnten doch auch
einfach in /etc/usr/* lieben.
Was verbirgt sich hinter /etc/cron.d/daily usw? Warum gibt es hierfür
nochmal extra Verzeichnisse. Würden sich die dortigen Scripts nicht auch
direkt in ein crontab-file eintragen lassen?
verstehe ich wie cron bedient wird.
Allerdings verstehe ich nicht warum(!) cron so bedient wird.
Also ich versuche cron zu verstehen und welche Designentscheidungen bzw
Konzepte dahinterstehen.
Mein größtes Unverständnis besteht darin, dass die jeweiligen
crontab-files mit bzw über die Anwendung crontab editiert werden müssen,
anstatt einfach die crontab-files direkt mit einem editor (vi, emacs,
etc) zu editieren.
Warum ist das so? Welches Prinzip steckt dahinter?
Warum gibt es crontab-files in /var/spool/* ? Was hat dieser Teil des
Verzeichnisbaums damit zu tun? Die crontab-files könnten doch auch
einfach in /etc/usr/* lieben.
Was verbirgt sich hinter /etc/cron.d/daily usw? Warum gibt es hierfür
nochmal extra Verzeichnisse. Würden sich die dortigen Scripts nicht auch
direkt in ein crontab-file eintragen lassen?
Subject: Re: cron verstehen
Date: Thu, 8 May 2008 01:54:41 +0000 (UTC)
Christian Buhtz <exsudat@gmx.de> wrote:
> Mein größtes Unverständnis besteht darin, dass die jeweiligen
> crontab-files mit bzw über die Anwendung crontab editiert werden müssen,
> anstatt einfach die crontab-files direkt mit einem editor (vi, emacs,
> etc) zu editieren.
> Warum ist das so? Welches Prinzip steckt dahinter?
Das Systemweite cron file wird tatsächlich direkt überwacht. Das Konzept das
File per command zu editieren hat mehrere Gründe:
a) Das File muss nicht überwacht werden sondern der reload kann nach dem exit des editors aufgerufen werden
b) man kann ein syntaxcheck durchführen bevor das file akzeptiert wird
c) manche crons legen die files mit bestimmten Zugriffsrechten ab, das liegt unter anderem an dem Problem eines zentralen Verzeichnisses (was natuerlich doof ist)
d) locking
> Warum gibt es crontab-files in /var/spool/* ? Was hat dieser Teil des
> Verzeichnisbaums damit zu tun? Die crontab-files könnten doch auch
> einfach in /etc/usr/* lieben.
Das ist mehr oder weniger histerisch :)
> Was verbirgt sich hinter /etc/cron.d/daily usw? Warum gibt es hierfür
> nochmal extra Verzeichnisse. Würden sich die dortigen Scripts nicht auch
> direkt in ein crontab-file eintragen lassen?
Das ist ein Zugestaendnis an die Package Manager der Neuzeit. Ein Paket das
einen Aufraeumjob hat muss nicht mehr crontab Files "automatisch" editieren (und
dabei noch sinnvolle Uhrzeiten finden), sondern er legt einfach ein Script
mit dem paketname in das Dir (oder löscht es beim uninstall).
Das klappt dann auch wenn nicht zu festen Zeiten ausgeführt wird sondern mit
einer unschaerfe die Systeme abdeckt die nicht immer an sind (z.b. anacron).
Die Einstellung wann das Daily Maintenance Window ist muss der Package
Ersteller garnicht treffen/wissen.
Ausserdem kann dann der Job Executor die max. Parallelität selbst wählen.
(i.A. =1)
Gruss
Bernd
> Mein größtes Unverständnis besteht darin, dass die jeweiligen
> crontab-files mit bzw über die Anwendung crontab editiert werden müssen,
> anstatt einfach die crontab-files direkt mit einem editor (vi, emacs,
> etc) zu editieren.
> Warum ist das so? Welches Prinzip steckt dahinter?
Das Systemweite cron file wird tatsächlich direkt überwacht. Das Konzept das
File per command zu editieren hat mehrere Gründe:
a) Das File muss nicht überwacht werden sondern der reload kann nach dem exit des editors aufgerufen werden
b) man kann ein syntaxcheck durchführen bevor das file akzeptiert wird
c) manche crons legen die files mit bestimmten Zugriffsrechten ab, das liegt unter anderem an dem Problem eines zentralen Verzeichnisses (was natuerlich doof ist)
d) locking
> Warum gibt es crontab-files in /var/spool/* ? Was hat dieser Teil des
> Verzeichnisbaums damit zu tun? Die crontab-files könnten doch auch
> einfach in /etc/usr/* lieben.
Das ist mehr oder weniger histerisch :)
> Was verbirgt sich hinter /etc/cron.d/daily usw? Warum gibt es hierfür
> nochmal extra Verzeichnisse. Würden sich die dortigen Scripts nicht auch
> direkt in ein crontab-file eintragen lassen?
Das ist ein Zugestaendnis an die Package Manager der Neuzeit. Ein Paket das
einen Aufraeumjob hat muss nicht mehr crontab Files "automatisch" editieren (und
dabei noch sinnvolle Uhrzeiten finden), sondern er legt einfach ein Script
mit dem paketname in das Dir (oder löscht es beim uninstall).
Das klappt dann auch wenn nicht zu festen Zeiten ausgeführt wird sondern mit
einer unschaerfe die Systeme abdeckt die nicht immer an sind (z.b. anacron).
Die Einstellung wann das Daily Maintenance Window ist muss der Package
Ersteller garnicht treffen/wissen.
Ausserdem kann dann der Job Executor die max. Parallelität selbst wählen.
(i.A. =1)
Gruss
Bernd
Subject: Re: cron verstehen
Date: 08 May 2008 06:11:50 GMT
Hallo,
Christian Buhtz <exsudat@gmx.de> wrote:
> Ich habe bereits die manpages zu cron und crontab gelesen. Soweit
> verstehe ich wie cron bedient wird.
???
> Allerdings verstehe ich nicht warum(!) cron so bedient wird.
> Also ich versuche cron zu verstehen und welche Designentscheidungen bzw
> Konzepte dahinterstehen.
> Mein größtes Unverständnis besteht darin, dass die jeweiligen
> crontab-files mit bzw über die Anwendung crontab editiert werden müssen,
> anstatt einfach die crontab-files direkt mit einem editor (vi, emacs,
> etc) zu editieren.
> Warum ist das so? Welches Prinzip steckt dahinter?
Das ist doch ganz einfach: zum einen hat man dadurch eine "einheitlichere
Bedienung ueber Systemgrenzen hinweg" (denn der Ort, wo die crontabs liegen
ist nicht auf allen Systemen gleich, wenn man auch mal ueber den Linux-
Tellerrand hinaussieht), zum anderen ermoeglicht diese Methode es, die
"neuen crontabs" auf "syntaktische Korrektheit" zu pruefen, bevor sie
uebernommen werden, und schliesslich ermoeglicht es den Usern ihre eigene
crontab zu editieren, auch wenn sie (wegen restriktiver Zugriffsrechte)
nicht in das Verzeichnis mit den crontabs schreiben duerfen. Ach ja, und
dann sorgt crontab noch fuer das passende "locking" der Dateien (so dass
nicht versehentlich die selbe crontab-Datei mehrfach gleichzeitig editiert
wird, und dann "die zuletzt gespeicherte Version gewinnt" und die anderen
Aenderungen unberuecksichtigt bleiben ...).
> Warum gibt es crontab-files in /var/spool/* ? Was hat dieser Teil des
> Verzeichnisbaums damit zu tun? Die crontab-files könnten doch auch
> einfach in /etc/usr/* lieben.
Gibt es denn ein /etc/usr? Bei mir zumindest nicht ...
> Was verbirgt sich hinter /etc/cron.d/daily usw? Warum gibt es hierfür
> nochmal extra Verzeichnisse. Würden sich die dortigen Scripts nicht auch
> direkt in ein crontab-file eintragen lassen?
Das ist eine Erweiterung des (weit verbreiteten) "Vixie-cron", die es nicht
bei jeder cron-Implementierung gibt (oder besser gesagt: die /etc/crontab
ist diese Erweiterung, und in der stehen die Aufrufe drin, die diese
"Verzeichnisse abarbeiten"). Diese (meines Erachtens nach zumindest teil-
weise fragwuerdige) design-Entscheidung erleichtert es bei der Installation
von Software-Paketen die Einrichtung, sofern fuer das Paket eigene crontab-
Eintraege benoetigt werden: der "Installer" muss dann nicht "crontab" auf-
rufen, pruefen ob der benoetigte crontab-Eintrag schon vorhanden ist und
ihn ggfs. hinzufuegen, sondern es packt einfach sein script in eines dieser
Verzeichnisse und damit ist der Fall gegessen. Ebenso lassen sich solche
cron-jobs dadurch bei De-Installation des Pakets auch genauso einfach wieder
automatisch abraeumen (du wirst einsehen, dass das "richtige Zeile aus der
crontab heraussuschen und diese Zeile loeschen ohne den Restanzutasten" da
erheblich schwieriger waere ...).
Tschuess,
Juergen Ilse (juergen@usenet-verwaltung.de)
--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...
Christian Buhtz <exsudat@gmx.de> wrote:
> Ich habe bereits die manpages zu cron und crontab gelesen. Soweit
> verstehe ich wie cron bedient wird.
???
> Allerdings verstehe ich nicht warum(!) cron so bedient wird.
> Also ich versuche cron zu verstehen und welche Designentscheidungen bzw
> Konzepte dahinterstehen.
> Mein größtes Unverständnis besteht darin, dass die jeweiligen
> crontab-files mit bzw über die Anwendung crontab editiert werden müssen,
> anstatt einfach die crontab-files direkt mit einem editor (vi, emacs,
> etc) zu editieren.
> Warum ist das so? Welches Prinzip steckt dahinter?
Das ist doch ganz einfach: zum einen hat man dadurch eine "einheitlichere
Bedienung ueber Systemgrenzen hinweg" (denn der Ort, wo die crontabs liegen
ist nicht auf allen Systemen gleich, wenn man auch mal ueber den Linux-
Tellerrand hinaussieht), zum anderen ermoeglicht diese Methode es, die
"neuen crontabs" auf "syntaktische Korrektheit" zu pruefen, bevor sie
uebernommen werden, und schliesslich ermoeglicht es den Usern ihre eigene
crontab zu editieren, auch wenn sie (wegen restriktiver Zugriffsrechte)
nicht in das Verzeichnis mit den crontabs schreiben duerfen. Ach ja, und
dann sorgt crontab noch fuer das passende "locking" der Dateien (so dass
nicht versehentlich die selbe crontab-Datei mehrfach gleichzeitig editiert
wird, und dann "die zuletzt gespeicherte Version gewinnt" und die anderen
Aenderungen unberuecksichtigt bleiben ...).
> Warum gibt es crontab-files in /var/spool/* ? Was hat dieser Teil des
> Verzeichnisbaums damit zu tun? Die crontab-files könnten doch auch
> einfach in /etc/usr/* lieben.
Gibt es denn ein /etc/usr? Bei mir zumindest nicht ...
> Was verbirgt sich hinter /etc/cron.d/daily usw? Warum gibt es hierfür
> nochmal extra Verzeichnisse. Würden sich die dortigen Scripts nicht auch
> direkt in ein crontab-file eintragen lassen?
Das ist eine Erweiterung des (weit verbreiteten) "Vixie-cron", die es nicht
bei jeder cron-Implementierung gibt (oder besser gesagt: die /etc/crontab
ist diese Erweiterung, und in der stehen die Aufrufe drin, die diese
"Verzeichnisse abarbeiten"). Diese (meines Erachtens nach zumindest teil-
weise fragwuerdige) design-Entscheidung erleichtert es bei der Installation
von Software-Paketen die Einrichtung, sofern fuer das Paket eigene crontab-
Eintraege benoetigt werden: der "Installer" muss dann nicht "crontab" auf-
rufen, pruefen ob der benoetigte crontab-Eintrag schon vorhanden ist und
ihn ggfs. hinzufuegen, sondern es packt einfach sein script in eines dieser
Verzeichnisse und damit ist der Fall gegessen. Ebenso lassen sich solche
cron-jobs dadurch bei De-Installation des Pakets auch genauso einfach wieder
automatisch abraeumen (du wirst einsehen, dass das "richtige Zeile aus der
crontab heraussuschen und diese Zeile loeschen ohne den Restanzutasten" da
erheblich schwieriger waere ...).
Tschuess,
Juergen Ilse (juergen@usenet-verwaltung.de)
--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...
Subject: Re: cron verstehen
Date: Thu, 08 May 2008 10:52:44 +0200
Juergen Ilse <ilse@usenet-verwaltung.de> writes:
> Christian Buhtz <exsudat@gmx.de> wrote:
[...]
>> Was verbirgt sich hinter /etc/cron.d/daily usw? Warum gibt es hierfür
>> nochmal extra Verzeichnisse. Würden sich die dortigen Scripts nicht auch
>> direkt in ein crontab-file eintragen lassen?
>
[...]
> der "Installer" muss dann nicht "crontab" aufrufen, pruefen ob der
> benoetigte crontab-Eintrag schon vorhanden ist und ihn
> ggfs. hinzufuegen, sondern es packt einfach sein script in eines
> dieser Verzeichnisse und damit ist der Fall gegessen. Ebenso lassen
> sich solche cron-jobs dadurch bei De-Installation des Pakets auch
> genauso einfach wieder automatisch abraeumen (du wirst einsehen,
> dass das "richtige Zeile aus der crontab heraussuschen und diese
> Zeile loeschen ohne den Restanzutasten" da
> erheblich schwieriger waere ...).
ed /etc/crontab <<EOF
/[ ]/my\/cron\/command$/d
w
q
EOF
Allerdings hat die Methode mit den .d-Verzeichnissen (wenigstens
theoretisch) noch ein paar andere Vorteile. ZB gibt es keine Probleme
mit moeglichen Doppeleintraegen und es kann 'recht einfach' maschinell
ueberprueft werden, ob jemand ein solches Skript geaendert hat.
> Christian Buhtz <exsudat@gmx.de> wrote:
[...]
>> Was verbirgt sich hinter /etc/cron.d/daily usw? Warum gibt es hierfür
>> nochmal extra Verzeichnisse. Würden sich die dortigen Scripts nicht auch
>> direkt in ein crontab-file eintragen lassen?
>
[...]
> der "Installer" muss dann nicht "crontab" aufrufen, pruefen ob der
> benoetigte crontab-Eintrag schon vorhanden ist und ihn
> ggfs. hinzufuegen, sondern es packt einfach sein script in eines
> dieser Verzeichnisse und damit ist der Fall gegessen. Ebenso lassen
> sich solche cron-jobs dadurch bei De-Installation des Pakets auch
> genauso einfach wieder automatisch abraeumen (du wirst einsehen,
> dass das "richtige Zeile aus der crontab heraussuschen und diese
> Zeile loeschen ohne den Restanzutasten" da
> erheblich schwieriger waere ...).
ed /etc/crontab <<EOF
/[ ]/my\/cron\/command$/d
w
q
EOF
Allerdings hat die Methode mit den .d-Verzeichnissen (wenigstens
theoretisch) noch ein paar andere Vorteile. ZB gibt es keine Probleme
mit moeglichen Doppeleintraegen und es kann 'recht einfach' maschinell
ueberprueft werden, ob jemand ein solches Skript geaendert hat.
Subject: Re: cron verstehen
Date: Thu, 08 May 2008 12:28:43 +0200
Juergen Ilse wrote (2008-05-08 08:11):
> Ebenso lassen sich solche
> cron-jobs dadurch bei De-Installation des Pakets auch genauso einfach wieder
> automatisch abraeumen (du wirst einsehen, dass das "richtige Zeile aus der
> crontab heraussuschen und diese Zeile loeschen ohne den Restanzutasten" da
> erheblich schwieriger waere ...).
Warum? Jeder Eintrag steht in einer eigenen Zeile. Die kann ich doch
leicht löschen, ohne die anderen anzufassen? Und wenn man nicht weiß,
was in der zu entfernenden Zeile steht, dann macht man davor und
dahinter eine eindeutige Kommentarzeile.
Dann kann man mit crontab -l alles sehen und muß nicht noch in 5 andere
Dateien schauen.
--
* Origin: Fido over IP (2:240/2188.575)
> Ebenso lassen sich solche
> cron-jobs dadurch bei De-Installation des Pakets auch genauso einfach wieder
> automatisch abraeumen (du wirst einsehen, dass das "richtige Zeile aus der
> crontab heraussuschen und diese Zeile loeschen ohne den Restanzutasten" da
> erheblich schwieriger waere ...).
Warum? Jeder Eintrag steht in einer eigenen Zeile. Die kann ich doch
leicht löschen, ohne die anderen anzufassen? Und wenn man nicht weiß,
was in der zu entfernenden Zeile steht, dann macht man davor und
dahinter eine eindeutige Kommentarzeile.
Dann kann man mit crontab -l alles sehen und muß nicht noch in 5 andere
Dateien schauen.
--
* Origin: Fido over IP (2:240/2188.575)
Subject: Re: cron verstehen
Date: Thu, 08 May 2008 12:48:14 +0200
Gerhard Strangar <g.s@arcor.de> writes:
> Juergen Ilse wrote (2008-05-08 08:11):
>> Ebenso lassen sich solche
>> cron-jobs dadurch bei De-Installation des Pakets auch genauso einfach wieder
>> automatisch abraeumen (du wirst einsehen, dass das "richtige Zeile aus der
>> crontab heraussuschen und diese Zeile loeschen ohne den Restanzutasten" da
>> erheblich schwieriger waere ...).
>
> Warum? Jeder Eintrag steht in einer eigenen Zeile. Die kann ich doch
> leicht löschen, ohne die anderen anzufassen? Und wenn man nicht weiß,
> was in der zu entfernenden Zeile steht, dann macht man davor und
> dahinter eine eindeutige Kommentarzeile.
> Dann kann man mit crontab -l alles sehen und muß nicht noch in 5 andere
> Dateien schauen.
Das ist ja genau der tradeoff, den Juergen schon 'fragwuerdig' fand:
Man nimmt in Kauf, dass das Gesamtsystem etwas umstaendlicher manuell
zu handhaben ist, um es etwas einfacher automatisiert aendern zu
koennen.
> Juergen Ilse wrote (2008-05-08 08:11):
>> Ebenso lassen sich solche
>> cron-jobs dadurch bei De-Installation des Pakets auch genauso einfach wieder
>> automatisch abraeumen (du wirst einsehen, dass das "richtige Zeile aus der
>> crontab heraussuschen und diese Zeile loeschen ohne den Restanzutasten" da
>> erheblich schwieriger waere ...).
>
> Warum? Jeder Eintrag steht in einer eigenen Zeile. Die kann ich doch
> leicht löschen, ohne die anderen anzufassen? Und wenn man nicht weiß,
> was in der zu entfernenden Zeile steht, dann macht man davor und
> dahinter eine eindeutige Kommentarzeile.
> Dann kann man mit crontab -l alles sehen und muß nicht noch in 5 andere
> Dateien schauen.
Das ist ja genau der tradeoff, den Juergen schon 'fragwuerdig' fand:
Man nimmt in Kauf, dass das Gesamtsystem etwas umstaendlicher manuell
zu handhaben ist, um es etwas einfacher automatisiert aendern zu
koennen.
Subject: Re: cron verstehen
Date: 08 May 2008 12:49:46 GMT
Hallo,
Gerhard Strangar <g.s@arcor.de> wrote:
> Juergen Ilse wrote (2008-05-08 08:11):
>> Ebenso lassen sich solche
>> cron-jobs dadurch bei De-Installation des Pakets auch genauso einfach wieder
>> automatisch abraeumen (du wirst einsehen, dass das "richtige Zeile aus der
>> crontab heraussuschen und diese Zeile loeschen ohne den Restanzutasten" da
>> erheblich schwieriger waere ...).
> Warum? Jeder Eintrag steht in einer eigenen Zeile. Die kann ich doch
> leicht löschen, ohne die anderen anzufassen? Und wenn man nicht weiß,
> was in der zu entfernenden Zeile steht, dann macht man davor und
> dahinter eine eindeutige Kommentarzeile.
Es ist leichter eine Datei mit bekanntem Namen zu loeschen als eine crontab
nach einer (oderschlimmstenfalls mehreren) Zeilen mit bekanntem Inhalt zu
durchsuchen, diese zu loeschen und den Rest der crontab unangetastet zu
lassen (insbesondere dann, wenn die crontab evt. auch noch manuell editiert
wurde und dabei vielleicht in die "Zeile mit bekanntem Inhalt" ein an sich
wirkungsloses Leerzeichen mit hineingeraten sein sollte ...).
> Dann kann man mit crontab -l alles sehen und muß nicht noch in 5 andere
> Dateien schauen.
Diese cronjobs sind als "gehoert zu Paket soundso und hat gefaelligst nicht
manuell geaendert zu werden" gemeint, so dass es insofern vom Distributor
wohl sogar eher *gewuenscht* ist, dass dort nicht manuiell dran herumge-
schraubt wird. Insofern ist es aus Sicht des Distributors sogar sinnvoll,
dass diese cron-Jobs nicht mit "crontab -l" aufgelistet werden ...
Wie ich bereits schrieb: ich mag die Methode nicht besonders, aber ich hoffe
erlaeutert zu haben, weshalb viele Distributoren das vermutlich anders sehen.
Tschuess,
Juergen Ilse (juergen@usenet-verwaltung.de)
--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...
Gerhard Strangar <g.s@arcor.de> wrote:
> Juergen Ilse wrote (2008-05-08 08:11):
>> Ebenso lassen sich solche
>> cron-jobs dadurch bei De-Installation des Pakets auch genauso einfach wieder
>> automatisch abraeumen (du wirst einsehen, dass das "richtige Zeile aus der
>> crontab heraussuschen und diese Zeile loeschen ohne den Restanzutasten" da
>> erheblich schwieriger waere ...).
> Warum? Jeder Eintrag steht in einer eigenen Zeile. Die kann ich doch
> leicht löschen, ohne die anderen anzufassen? Und wenn man nicht weiß,
> was in der zu entfernenden Zeile steht, dann macht man davor und
> dahinter eine eindeutige Kommentarzeile.
Es ist leichter eine Datei mit bekanntem Namen zu loeschen als eine crontab
nach einer (oderschlimmstenfalls mehreren) Zeilen mit bekanntem Inhalt zu
durchsuchen, diese zu loeschen und den Rest der crontab unangetastet zu
lassen (insbesondere dann, wenn die crontab evt. auch noch manuell editiert
wurde und dabei vielleicht in die "Zeile mit bekanntem Inhalt" ein an sich
wirkungsloses Leerzeichen mit hineingeraten sein sollte ...).
> Dann kann man mit crontab -l alles sehen und muß nicht noch in 5 andere
> Dateien schauen.
Diese cronjobs sind als "gehoert zu Paket soundso und hat gefaelligst nicht
manuell geaendert zu werden" gemeint, so dass es insofern vom Distributor
wohl sogar eher *gewuenscht* ist, dass dort nicht manuiell dran herumge-
schraubt wird. Insofern ist es aus Sicht des Distributors sogar sinnvoll,
dass diese cron-Jobs nicht mit "crontab -l" aufgelistet werden ...
Wie ich bereits schrieb: ich mag die Methode nicht besonders, aber ich hoffe
erlaeutert zu haben, weshalb viele Distributoren das vermutlich anders sehen.
Tschuess,
Juergen Ilse (juergen@usenet-verwaltung.de)
--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...
Subject: Re: cron verstehen
Date: Thu, 8 May 2008 21:39:12 +0000 (UTC)
Juergen Ilse <ilse@usenet-verwaltung.de> wrote:
> dass diese cron-Jobs nicht mit "crontab -l" aufgelistet werden ...
Also ein "was laeuft jeden tag?" mit "ls -l /etc/cron.daily" zu beantworten
halte ich für übersichtlicher als 6 spalten mit sternchen zu interpretieren.
Gruss
Bernd
> dass diese cron-Jobs nicht mit "crontab -l" aufgelistet werden ...
Also ein "was laeuft jeden tag?" mit "ls -l /etc/cron.daily" zu beantworten
halte ich für übersichtlicher als 6 spalten mit sternchen zu interpretieren.
Gruss
Bernd
Subject: Re: cron verstehen
Date: 08 May 2008 22:59:18 GMT
Hallo,
Bernd Eckenfels <ecki@lina.inka.de> wrote:
> Juergen Ilse <ilse@usenet-verwaltung.de> wrote:
>> dass diese cron-Jobs nicht mit "crontab -l" aufgelistet werden ...
> Also ein "was laeuft jeden tag?" mit "ls -l /etc/cron.daily" zu beantworten
> halte ich für übersichtlicher als 6 spalten mit sternchen zu interpretieren.
Nur ist ja cron-daily nicht *anstelle* der regulaeren crontabs da
sondern *zusaetzlich* ... Um also umfassende Informationen zu erhalten,
benoetigt man nun noch ein Kommando *zusaetzlich* ...
Tschuess,
Juergen Ilse (juergen@usenet-verwaltung.de)
--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...
Bernd Eckenfels <ecki@lina.inka.de> wrote:
> Juergen Ilse <ilse@usenet-verwaltung.de> wrote:
>> dass diese cron-Jobs nicht mit "crontab -l" aufgelistet werden ...
> Also ein "was laeuft jeden tag?" mit "ls -l /etc/cron.daily" zu beantworten
> halte ich für übersichtlicher als 6 spalten mit sternchen zu interpretieren.
Nur ist ja cron-daily nicht *anstelle* der regulaeren crontabs da
sondern *zusaetzlich* ... Um also umfassende Informationen zu erhalten,
benoetigt man nun noch ein Kommando *zusaetzlich* ...
Tschuess,
Juergen Ilse (juergen@usenet-verwaltung.de)
--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...
Subject: Re: cron verstehen
Date: Thu, 8 May 2008 21:36:53 +0000 (UTC)
Gerhard Strangar <g.s@arcor.de> wrote:
> Warum? Jeder Eintrag steht in einer eigenen Zeile. Die kann ich doch
> leicht löschen, ohne die anderen anzufassen?
Solange sie nicht veraendert wurde. Und was machst du bei Continuation. Oder
bei mehren auskommentierten Zeilen? Klar kann man das alles irgendwie lösen,
aber schon DJB sagte "dont parse".
Gruss
Bernd
> Warum? Jeder Eintrag steht in einer eigenen Zeile. Die kann ich doch
> leicht löschen, ohne die anderen anzufassen?
Solange sie nicht veraendert wurde. Und was machst du bei Continuation. Oder
bei mehren auskommentierten Zeilen? Klar kann man das alles irgendwie lösen,
aber schon DJB sagte "dont parse".
Gruss
Bernd
Subject: Re: cron verstehen
Date: Fri, 09 May 2008 12:11:14 +0200
Bernd Eckenfels wrote (2008-05-08 23:36):
>> Warum? Jeder Eintrag steht in einer eigenen Zeile. Die kann ich doch
>> leicht löschen, ohne die anderen anzufassen?
> Solange sie nicht veraendert wurde. Und was machst du bei Continuation. Oder
> bei mehren auskommentierten Zeilen? Klar kann man das alles irgendwie lösen,
> aber schon DJB sagte "dont parse".
Ganz einfach:
Ich füge eine Kommentarzeile ein, danach den Cronjob und wieder eine
Kommentarzeile. Zum Löschen wird von Kommentar zu Kommentar gelöscht und
ob die Zeile sich geändert hat, etc. spielt keine Rolle.
--
* Origin: Fido over IP (2:240/2188.575)
>> Warum? Jeder Eintrag steht in einer eigenen Zeile. Die kann ich doch
>> leicht löschen, ohne die anderen anzufassen?
> Solange sie nicht veraendert wurde. Und was machst du bei Continuation. Oder
> bei mehren auskommentierten Zeilen? Klar kann man das alles irgendwie lösen,
> aber schon DJB sagte "dont parse".
Ganz einfach:
Ich füge eine Kommentarzeile ein, danach den Cronjob und wieder eine
Kommentarzeile. Zum Löschen wird von Kommentar zu Kommentar gelöscht und
ob die Zeile sich geändert hat, etc. spielt keine Rolle.
--
* Origin: Fido over IP (2:240/2188.575)
Subject: Re: cron verstehen
Date: Fri, 09 May 2008 19:31:47 +0200
Bernd Eckenfels <ecki@lina.inka.de> writes:
> Gerhard Strangar <g.s@arcor.de> wrote:
>> Warum? Jeder Eintrag steht in einer eigenen Zeile. Die kann ich doch
>> leicht löschen, ohne die anderen anzufassen?
>
> Solange sie nicht veraendert wurde. Und was machst du bei Continuation. Oder
> bei mehren auskommentierten Zeilen? Klar kann man das alles irgendwie lösen,
> aber schon DJB sagte "dont parse".
DJB 'sagte' auch schon, dass es die Loesung fuer von
Inkompatiblitaeten zwischen unterschiedlichen unixoiden Systemen
herruehrende Probleme sei, alles nochmal von vorne ganz anders zu
machen, bloss diesmal, so wie er es fuer richtig hielte. Ich wuerde
eine Wette darauf eingehen, dass seine n Vorgaenger, derentwegen diese
x * n mehr oder minder inkompatiblen Ordnungschemata existieren,
bereits genau derselben Ansicht waren ...
> Gerhard Strangar <g.s@arcor.de> wrote:
>> Warum? Jeder Eintrag steht in einer eigenen Zeile. Die kann ich doch
>> leicht löschen, ohne die anderen anzufassen?
>
> Solange sie nicht veraendert wurde. Und was machst du bei Continuation. Oder
> bei mehren auskommentierten Zeilen? Klar kann man das alles irgendwie lösen,
> aber schon DJB sagte "dont parse".
DJB 'sagte' auch schon, dass es die Loesung fuer von
Inkompatiblitaeten zwischen unterschiedlichen unixoiden Systemen
herruehrende Probleme sei, alles nochmal von vorne ganz anders zu
machen, bloss diesmal, so wie er es fuer richtig hielte. Ich wuerde
eine Wette darauf eingehen, dass seine n Vorgaenger, derentwegen diese
x * n mehr oder minder inkompatiblen Ordnungschemata existieren,
bereits genau derselben Ansicht waren ...
Subject: Re: cron verstehen
Date: Sat, 10 May 2008 06:00:32 +0000 (UTC)
Bernd Eckenfels <ecki@lina.inka.de>:
> Gerhard Strangar <g.s@arcor.de> wrote:
>> Warum? Jeder Eintrag steht in einer eigenen Zeile. Die kann ich doch
>> leicht löschen, ohne die anderen anzufassen?
>
> Solange sie nicht veraendert wurde. Und was machst du bei Continuation. Oder
> bei mehren auskommentierten Zeilen? Klar kann man das alles irgendwie lösen,
> aber schon DJB sagte "dont parse".
DJB, das war doch der ohne jegliches Paketmanagement und ohne
konsistente Dateistruktur in seinen WFM-syndrombehafteten Projekten?
Wer's nicht kann, sollte in der Tat die Finger davon lassen (parsing).
Juergen
> Gerhard Strangar <g.s@arcor.de> wrote:
>> Warum? Jeder Eintrag steht in einer eigenen Zeile. Die kann ich doch
>> leicht löschen, ohne die anderen anzufassen?
>
> Solange sie nicht veraendert wurde. Und was machst du bei Continuation. Oder
> bei mehren auskommentierten Zeilen? Klar kann man das alles irgendwie lösen,
> aber schon DJB sagte "dont parse".
DJB, das war doch der ohne jegliches Paketmanagement und ohne
konsistente Dateistruktur in seinen WFM-syndrombehafteten Projekten?
Wer's nicht kann, sollte in der Tat die Finger davon lassen (parsing).
Juergen
Subject: Re: cron verstehen
Date: Sat, 10 May 2008 15:27:11 +0200
Juergen P. Meier schrieb:
> DJB
Könnt ihr mich jetzt mal über "DJB" aufklären bitte. Wer is das? Was hat
er/sie gemacht?
> DJB
Könnt ihr mich jetzt mal über "DJB" aufklären bitte. Wer is das? Was hat
er/sie gemacht?
Subject: Re: cron verstehen
Date: 10 May 2008 15:04:05 GMT
Christian Buhtz wrote:
> Juergen P. Meier schrieb:
>> DJB
> Könnt ihr mich jetzt mal über "DJB" aufklären bitte. Wer is das? Was hat
> er/sie gemacht?
Ich hätte gesagt, der da:
<http://en.wikipedia.org/wiki/DJB>
Toni
--
Pessimismus ist noch viel zu optimistisch
> Juergen P. Meier schrieb:
>> DJB
> Könnt ihr mich jetzt mal über "DJB" aufklären bitte. Wer is das? Was hat
> er/sie gemacht?
Ich hätte gesagt, der da:
<http://en.wikipedia.org/wiki/DJB>
Toni
--
Pessimismus ist noch viel zu optimistisch
Subject: Re: cron verstehen
Date: Sun, 11 May 2008 09:17:00 +0200
Christian Buhtz <exsudat@gmx.de> writes:
> Juergen P. Meier schrieb:
>> DJB
>
> Könnt ihr mich jetzt mal über "DJB" aufklären bitte. Wer is das? Was
> hat er/sie gemacht?
Ich versuche es mal mit einer kurzen Beschreibung:
Professor fuer Mathematik an einer amerikanischen Universitaet, der
einen nennenswerten Teil seiner Zeit damit verbringt (oder verbrachte)
Alternativen fuer verschiedene 'da facto'-UNIX(*)-Standardsoftware zu
entwickeln, die sich bezueglich verschiedener Aspekte eher so
verhielten, wie ihm das sinnvoll erschien, der aufgrund seines
rueden oeffentlichen (Internet) Auftretens eine mitunter recht
lautstarke weltweite Fan-Gemeinde hat.
> Juergen P. Meier schrieb:
>> DJB
>
> Könnt ihr mich jetzt mal über "DJB" aufklären bitte. Wer is das? Was
> hat er/sie gemacht?
Ich versuche es mal mit einer kurzen Beschreibung:
Professor fuer Mathematik an einer amerikanischen Universitaet, der
einen nennenswerten Teil seiner Zeit damit verbringt (oder verbrachte)
Alternativen fuer verschiedene 'da facto'-UNIX(*)-Standardsoftware zu
entwickeln, die sich bezueglich verschiedener Aspekte eher so
verhielten, wie ihm das sinnvoll erschien, der aufgrund seines
rueden oeffentlichen (Internet) Auftretens eine mitunter recht
lautstarke weltweite Fan-Gemeinde hat.
Subject: Re: cron verstehen
Date: 11 May 2008 19:33:34 GMT
Hallo,
Christian Buhtz <exsudat@gmx.de> wrote:
> Juergen P. Meier schrieb:
>> DJB
> Könnt ihr mich jetzt mal über "DJB" aufklären bitte. Wer is das? Was hat
> er/sie gemacht?
Dan J. Bernstein. Der Autor von Qmail und djbdns. Der MAnn hatte unter
anderem auch die eher krank anmutende Idee, dass ja Zonentranfers bei
DNS voellig ueberfluessig seien und das man dort, wo man sie benoetigen
wuerde, besser die Zonen per "scp" zwischen den beteiligten DNS-Servern
hin und her kopiert (was in real existierenden Umgebingen voellig praxis-
fremd ist). Auch hatte er den Sinn von "mehreren unabhaengigen DNS-Servern"
nicht verstanden und seine eigene Domain "yp.to" eine zeitlang mit "zwei"
DNS-Servern betrieben, die "zufaellig die selbe IP-Adresse" hatten ...
Tschuess,
Juergen Ilse (juergen@usenet-verwaltung.de)
--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...
Christian Buhtz <exsudat@gmx.de> wrote:
> Juergen P. Meier schrieb:
>> DJB
> Könnt ihr mich jetzt mal über "DJB" aufklären bitte. Wer is das? Was hat
> er/sie gemacht?
Dan J. Bernstein. Der Autor von Qmail und djbdns. Der MAnn hatte unter
anderem auch die eher krank anmutende Idee, dass ja Zonentranfers bei
DNS voellig ueberfluessig seien und das man dort, wo man sie benoetigen
wuerde, besser die Zonen per "scp" zwischen den beteiligten DNS-Servern
hin und her kopiert (was in real existierenden Umgebingen voellig praxis-
fremd ist). Auch hatte er den Sinn von "mehreren unabhaengigen DNS-Servern"
nicht verstanden und seine eigene Domain "yp.to" eine zeitlang mit "zwei"
DNS-Servern betrieben, die "zufaellig die selbe IP-Adresse" hatten ...
Tschuess,
Juergen Ilse (juergen@usenet-verwaltung.de)
--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...
Subject: Re: cron verstehen
Date: Sun, 11 May 2008 22:03:13 +0200
Juergen Ilse <ilse@usenet-verwaltung.de> wrote:
[...]
DJB-bashing war schon lange nicht mehr angesagt. ;-)
> Tschuess,
> Juergen Ilse (juergen@usenet-verwaltung.de)
Schönes Rest-Pfingsten noch + Servus,
Dietrich
[...]
DJB-bashing war schon lange nicht mehr angesagt. ;-)
> Tschuess,
> Juergen Ilse (juergen@usenet-verwaltung.de)
Schönes Rest-Pfingsten noch + Servus,
Dietrich