Hallo. Gibt es eine Möglichkeit, die crontab-Datei ohne einen Editor zu bearbeiten? Ich würde die Daten gerne in der Komandozeile direkt eingeben. Zum Beispiel crontab -e 50 13 15 7 * updatedb damit am 15.07. um 13:50 Uhr updatedb ausgeführt wird. Mir ist klar, dass es so wie oben nicht funktioniert. Habe ich schon getestet. Und in der Manpage steht leider auch nur, dass man crontab nur über einen Editor bearbeiten könne. Aber vielleicht gibt es ja doch eine Möglichkeit. Gruß Marcus
Hallo Marcus, Marcus Habermehl schrieb:
Hallo.
Gibt es eine Möglichkeit, die crontab-Datei ohne einen Editor zu bearbeiten? Ich würde die Daten gerne in der Komandozeile direkt eingeben.
Zum Beispiel
crontab -e 50 13 15 7 * updatedb
damit am 15.07. um 13:50 Uhr updatedb ausgeführt wird.
Mir ist klar, dass es so wie oben nicht funktioniert. Habe ich schon getestet. Und in der Manpage steht leider auch nur, dass man crontab nur über einen Editor bearbeiten könne.
Aber vielleicht gibt es ja doch eine Möglichkeit.
Schonmal 'crontab -e' versucht? Oder was meinst Du? Ansonsten funktioniert auch ein: 'echo "50 13 15 7 * updatedb" > meinecrontab' 'crontab meinecrontab' Gruss, Marc -- FH Furtwangen: http://www.psychology4u.de/cn/ Linux- und Netzwerkberatung: http://www.teamberatung.org Marc Mc Guinness: http://www.mcguinness.de PGP Public Key Block: http://mcguinness.psychology4u.de/public.txt
On Mon, 14 Jul 2003 at 23:14 (+0200), Marc Mc Guinness wrote:
Marcus Habermehl schrieb:
Ich würde die Daten gerne in der Komandozeile direkt eingeben. [...] Schonmal 'crontab -e' versucht? Oder was meinst Du?
Da geht ein Editor auf.
Ansonsten funktioniert auch ein: 'echo "50 13 15 7 * updatedb" > meinecrontab' 'crontab meinecrontab'
Das meinst Du nicht ernst, oder? So nach dem Motto: Du darfst keinen crontab-job neben mir haben? Dann sind nämlich alle vorher existierenden Jobs flöten: <schnipp> jan@k500:~> crontab -l # DO NOT EDIT THIS FILE - edit the master and reinstall. # (/tmp/crontab.1405 installed on Wed Jul 16 00:54:26 2003) # (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie # Exp $) 0 * * * * /bin/ls >/tmp/ls.txt jan@k500:~> echo "10 * * * * /bin/date >/tmp/date.txt" >mycron jan@k500:~> crontab mycron jan@k500:~> crontab -l # DO NOT EDIT THIS FILE - edit the master and reinstall. # (mycron installed on Wed Jul 16 00:55:43 2003) # (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie # Exp $) 10 * * * * /bin/date >/tmp/date.txt jan@k500:~> <schnapp> Also bitte so: crontab -l >meinecrontab echo "50 13 15 7 * updatedb" >>meinecrontab crontab meinecrontab Jan
Marcus Habermehl, Montag, 14. Juli 2003 23:01:
Gibt es eine Möglichkeit, die crontab-Datei ohne einen Editor zu bearbeiten? Ich würde die Daten gerne in der Komandozeile direkt eingeben.
Naja, das Problem ist ja, daß Du mit crontab -e nicht die crontab selbst bearbeitest, sondern nur eine Kopie davon. Sobald Du den Editor schließt, wird die bearbeitete Kopie so auf das Original zurückkopiert, daß der (ja laufende) crond sich nicht daran verschluckt, daß man ihm während einer Operation die crontab unterm Hintern weggezogen hat. So wie Du es gerne möchtest, würdest Du aber genau dieses riskieren. Daher denke ich, daß es keine Möglichkeit gibt, es sei denn, Du findest einen Editor, der sich über ein Makro so steuern läßt, daß Du Dein Ziel erreichst. Emacs kann ja angeblich alles. Vielleicht kann er auch dies? -- Andreas Feile www.feile.net
Hallo, On Mon, 14 Jul 2003, Marcus Habermehl schrieb:
Gibt es eine Möglichkeit, die crontab-Datei ohne einen Editor zu bearbeiten?
Nein[1]. Der Grund ist, dass man eben 'crontab -e' verwenden soll. -dnh [1] Zumindest nicht in einer Art die sinnvoll waere. -- Einer der beiden hat sich damals noch ziemlich auf den Schlips getreten gefühlt weil der Azubi (also meine Wenigkeit) denen klargemacht hat das die Idee scheiße ist. -- Thorsten Dahm in dasr
Am Montag Juli 14 2003 23:24 schrieb David Haller:
Hallo,
On Mon, 14 Jul 2003, Marcus Habermehl schrieb:
Gibt es eine Möglichkeit, die crontab-Datei ohne einen Editor zu bearbeiten?
Nein[1].
Der Grund ist, dass man eben 'crontab -e' verwenden soll.
Steht auch schon im Header eines solchen Files :) # DO NOT EDIT THIS FILE - edit the master and reinstall. # (/tmp/crontab.15020 installed on Wed Jun 4 20:09:20 2003) # (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $) Also ginge nur: crontab -lu USERNAME > FILENAME echo "blablubb" >>FILENAME crontab -u USERNAME FILENAME Allerdings kann es dann dazu kommen, das eine falche Crontab benutzt wird, wenn zwei oder mehrere Scriptaufrufe parallel oder kurz nacheinander ablaufen, was dann unter umständen eine falsche Crontab erzeugt. Man muß also die Crontab prüfen und falsche Zeilen überlesen lassen, was wiederum fatal sein kann. Gruß Udo -- Mail: udo@singollo.de oder udo.neist@t-online.de Hompage: http://www.singollo.de
Hallo Marcus, * Marcus schrieb am 14.07.2003:
Hallo.
Gibt es eine Möglichkeit, die crontab-Datei ohne einen Editor zu bearbeiten? Ich würde die Daten gerne in der Komandozeile direkt eingeben.
Zum Beispiel
crontab -e 50 13 15 7 * updatedb
damit am 15.07. um 13:50 Uhr updatedb ausgeführt wird.
Mir ist klar, dass es so wie oben nicht funktioniert. Habe ich schon getestet. Und in der Manpage steht leider auch nur, dass man crontab nur über einen Editor bearbeiten könne.
Aber vielleicht gibt es ja doch eine Möglichkeit.
Die User-Crontabs sind auf meinem Gentoo-System hier mit vcron unter /var/spool/cron/crontabs/ gespeichert. Ein Editieren einer User-dedizierten Crontab und anschließendes "crontab -e" zeigte, dass alles passt. Warum man die nicht editieren _sollte_, das weiß ich nicht. Ich kann mir auch nicht vorstellen, warum da ein Prozess schreibend darauf zugreifen sollte... Grüße, Tom
Thomas Preissler am Montag, 14. Juli 2003 23:46:
Hallo Marcus,
* Marcus schrieb am 14.07.2003:
Hallo.
Gibt es eine Möglichkeit, die crontab-Datei ohne einen Editor zu bearbeiten? Ich würde die Daten gerne in der Komandozeile direkt eingeben. [...]
Die User-Crontabs sind auf meinem Gentoo-System hier mit vcron unter /var/spool/cron/crontabs/ gespeichert. Ein Editieren einer User-dedizierten Crontab und anschließendes "crontab -e" zeigte, dass alles passt.
Warum man die nicht editieren _sollte_, das weiß ich nicht. Ich kann mir auch nicht vorstellen, warum da ein Prozess schreibend darauf zugreifen sollte...
z.B., um es in Scripten einfach handhaben zu können. Wie wäre es mit echo "<m> <h> <dom> <mon> <dow> <program>" \ >> /etc/spool/cron/crontabs/<user> (ggf. den Pfad der crontab anpassen, ich hab bei mir debian drauf!). Eine Alternative wäre 'at' (man at). -- Gruß MaxX 8-)
Am Dienstag, 15. Juli 2003 07:04 schrieb Matthias Houdek:
Thomas Preissler am Montag, 14. Juli 2003 23:46:
[...]
Warum man die nicht editieren _sollte_, das weiß ich nicht. Ich kann mir auch nicht vorstellen, warum da ein Prozess schreibend darauf zugreifen sollte...
z.B., um es in Scripten einfach handhaben zu können.
Genau dafür.
Wie wäre es mit
echo "<m> <h> <dom> <mon> <dow> <program>" \
/etc/spool/cron/crontabs/<user>
(ggf. den Pfad der crontab anpassen, ich hab bei mir debian drauf!).
Bei SuSE dürfte das dann /var/spool/cron/crontabs/ sein. Ein einfacher User hat aber schon keinen Zugriff auf /var/spool/cron. Am Montag, 14. Juli 2003 23:14 schrieb Marc Mc Guinness: [...]
Schonmal 'crontab -e' versucht? Oder was meinst Du? Ansonsten funktioniert auch ein: 'echo "50 13 15 7 * updatedb" > meinecrontab' 'crontab meinecrontab'
Die Möglichkeite kenne ich. Leider bleiben die alten Einträge dabei nicht vorhanden. Was man natürlich mit >> anstatt > umgehen könnte. Am Dienstag, 15. Juli 2003 10:19 schrieb Peter Wiersig:
Marcus Habermehl wrote:
Aber vielleicht gibt es ja doch eine Möglichkeit.
Ist ein "crontab --help" zu abwegig?
Habe ich gemacht. Na ja, eigentlich habe ich nur crontab eingegeben. Aber so genau wollen wir ja auch nicht sein. ;-)
Dann findest du die Verwendungsmoeglichkeit "crontab file", die deine crontab durch die angegebene Datei ersetzt. Hinzufuegen und Ersetzen kann man per "crontab -l | grep -v EntfernString >> neudatei" erreichen.
Das ist die fehlende Überlegung, auf die ich nicht gekommen bin. grep habe ich bisher nur ohne Argumente benutzt. Wahrscheinlich bin ich deshalb nicht darauf gekommen. Danke Marcus
Hallo, On Tue, 15 Jul 2003, Marcus Habermehl schrieb:
Bei SuSE dürfte das dann /var/spool/cron/crontabs/ sein. Ein einfacher User hat aber schon keinen Zugriff auf /var/spool/cron.
Und jetzt rate mal warum und warum es 'crontab -e' gibt... -dnh -- Nur weil manche Leute an einer Störung des translateralen Tag-Nacht-Rhythmus-Generators leiden, der eine koeffizientielle Verschiebung der monoversalen non-a-wake-Rekreationsphasen bewirkt, mußt du hier nicht so rumprollen... -- Sebastian Posner in asr
Am Mittwoch, 16. Juli 2003 03:28 schrieb David Haller:
Hallo,
On Tue, 15 Jul 2003, Marcus Habermehl schrieb:
Bei SuSE dürfte das dann /var/spool/cron/crontabs/ sein. Ein einfacher User hat aber schon keinen Zugriff auf /var/spool/cron.
Und jetzt rate mal warum und warum es 'crontab -e' gibt...
Weil der/die Programmierer gerne mit einem Editor gearbeitet hat? ;-) Ist meine Frage denn wirklich _so_ abwegig? Man kann doch den meisten Programmen Parameter übergeben. Zum Beispiel vim Datei. Und schon hat man die Datei geöffnet. Hätte ja auch sein können, dass es so ähnlich mit crontab geht. Gruß Marcus Habermehl
Marcus Habermehl wrote:
Aber vielleicht gibt es ja doch eine Möglichkeit.
Ist ein "crontab --help" zu abwegig? Dann findest du die Verwendungsmoeglichkeit "crontab file", die deine crontab durch die angegebene Datei ersetzt. Hinzufuegen und Ersetzen kann man per "crontab -l | grep -v EntfernString >> neudatei" erreichen. Welches wichtige Unix-Utility wie eine crontab kann man nicht skripten? -- Have fun, Peter
Hallo,
From: Marcus Habermehl [...] Aber vielleicht gibt es ja doch eine Möglichkeit.
...mir kommt da gerade mein Webmin ins Auge. 1. Mich würde interessieren wie der es macht. 2. Falls es zu kompliziert ist könnte man ja auch mit der Axt von hinten, .... ;) wget || lynx h++ps://[HOST Webmin]/cron/save_cron.cgi?[AUTH_INFO]&[...CRON_INFO]&[ZEIT_INFON]&.... Das FORM-Tag in Webmin's Formular sagt zumindest nichts über eine erzwungene Method (GET oder POST) aus. "<form action=save_cron.cgi>" Ich hab ebenfalls in naher Zukunft vor (muß), einige Jobs einer Web-Site auf zeitgesteuerte jobs auslagern (Auto-Archivierung, usw.), deshalb würde mich das auch mal interessieren. MfG Maik -------------------- ... aber es ist ja auch schon spät, oder ich bin verrückt.
Am Mittwoch, 16. Juli 2003 00:19 schrieb M. Bader:
Hallo,
From: Marcus Habermehl [...] Aber vielleicht gibt es ja doch eine Möglichkeit.
...mir kommt da gerade mein Webmin ins Auge.
[...] Durch den Webmin bin ich ja erst auf den Trichter gekommen. Wenn der das kann, müsste es ja auch eine Möglichkeit geben.
Ich hab ebenfalls in naher Zukunft vor (muß), einige Jobs einer Web-Site auf zeitgesteuerte jobs auslagern (Auto-Archivierung, usw.), deshalb würde mich das auch mal interessieren.
Ich habe das jetzt nach einem Ratschlag von Peter Wiersing gelöst. crontab -l | grep -v "#" > crontab.neu 20 20 16 07 * updatedb >> crontab.neu crontab crontab.neu Die erste Zeile sorgt dafür, dass alte Jobs vorhanden bleiben und die Kommentarzeilen nicht mehrfach in der Datei stehen. Will man dabei bekannte Jobs löschen, gibt man einfach deren Namen anstatt # an. Gruß Marcus Habermehl
Hallo,
From: Marcus Habermehl Ich habe das jetzt nach einem Ratschlag von Peter Wiersing gelöst.
Danke, werde es mal im Auge behalten. Und wie siehts denn eigentlich mit /etc/cron.daily aus? Werden Startscripte einfach in diesen Ordner geworfen, und um punkt 0:00 rattern dann alle Skripte los oder werden die nach einander abgearbeitet? (namentlich sortiert vielleicht, wie bei rc-Skripten?) Viele Grüße aus NS Maik
Am Donnerstag, 17. Juli 2003 09:07 schrieb M. Bader: [...]
Und wie siehts denn eigentlich mit /etc/cron.daily aus? Werden Startscripte einfach in diesen Ordner geworfen, und um punkt 0:00 rattern dann alle Skripte los oder werden die nach einander abgearbeitet? (namentlich sortiert vielleicht, wie bei rc-Skripten?)
Ich würde sagen nein. Die werden glaube ich beim Systemstart gestartet. Wann die das nächste mal laufen, kann ich nicht sagen. Bei mir z. B. ist dort ein Eintrag updatedb. Das habe ich aber über YaST deaktiviert und updatedb wird auch nicht automatisch gestartet. Gruß Marcus
* On Thu, 17 Jul 2003 at 16:54 +0200, Marcus Habermehl wrote:
Am Donnerstag, 17. Juli 2003 09:07 schrieb M. Bader: [...]
Und wie siehts denn eigentlich mit /etc/cron.daily aus? Werden Startscripte einfach in diesen Ordner geworfen, und um punkt 0:00 rattern dann alle Skripte los oder werden die nach einander abgearbeitet? (namentlich sortiert vielleicht, wie bei rc-Skripten?)
Ich würde sagen nein. Die werden glaube ich beim Systemstart gestartet. Wann die das nächste mal laufen, kann ich nicht sagen.
Es wird versucht, die Einträge einmal täglich zu starten. Die normale Startzeit ist IIRC 00:15. Wenn da der Computer nicht läuft, dann wird das Ding zum nächst möglichen Zeitpunkt gestartet; die Überprüfung dafür wird jede volle Viertelstunde durchgeführt. Merkt man recht schön am Beispiel updatedb - wenn der Rechner nciht über Nacht läuft, fängt er kurz nach dem Starten zum werkeln an. Wenn er über Nacht läuft, kriegt man um 00:15 das Zeichen endlich ins Bett zu gehen. /apm -- GPG welcome, request public key: mailto:adalbert+key@lopez.at
participants (11)
-
Adalbert Michelic -
Andreas Feile -
David Haller -
Jan.Trippler＠t-online.de -
M. Bader -
Marc Mc Guinness -
Marcus Habermehl -
Matthias Houdek -
Peter Wiersig -
Thomas Preissler -
udo.neist＠t-online.de