Im Format
1 | |
kann man die Ausführungszeit auf die Sekunde genau angeben. Nur schmeißt at die Sekundenangabe einfach weg. Ist das bei anderen Distributionen auch so?
"at" und "cron" sind üblicherweise 2 Seiten einer Medaille und "cron" löst nur Minuten auf.
at (cron?) scheint noch einen bösen Bug zu haben: Wenn man das System in einen Suspend Mode versetzt, verschiebt sich die Ausführungszeit um die Zeit, die die Kiste suspendiert war, in die Zukunft. sleep hat übrigens dasselbe Problem.
Hab mal nachgesehen. Debian/Ubuntu "at" hat einen eigenständigen Daemon, nutzt nicht cron. Das beschriebene Problem hängt direkt mit "sleep" zusammen, denn genau das macht "atd" bis zum nächsten Job. Wenn du nach der Suspendierung dem "atd" ein SIGHUP verpasst, dann wacht er auf. Die Ziel-Zeit ist in Minuten codiert. Hart. Da geht nix.
Eine feiner auflösende Alternative zu "cron" ist "mcron". "at" geht damit auch, Verhalten bei Suspend ist definiert. http://www.gnu.org/software/mcron/manual/html_node/index.html
A. K. schrieb: > Die Ziel-Zeit ist in Minuten codiert. Hart. Da geht nix. Da das Sekundenwegschmeißen dazu führt, daß der Job früher ausgeführt wird, ist die Sekundengenauigkeit mit einem sleep im Job selbst erreichbar - ist also nicht weiter schlimm. > Debian/Ubuntu "at" hat einen eigenständigen Daemon ... > "mcron". "at" geht damit auch, Verhalten bei Suspend ist definiert. Nutz at mit micron seinen eigenen Dämon nicht mehr? Zu dem at-Problem hab ich einen Bugreport geschrieben.
Gast
#3074187
Im Normallfall schmeisst at und cron die Sekunden weg, jedenfalls kenne ich dies seit SuSe 6.4. Bei sleep sind auch diese Ungenauigkeiten, es soll ja wenigsten die angegebene Zeit gewartet werden und nicht genau. Für den Fall das mal der Rechner ausgeschaltet wird und der cron Befehl erst nach einer gewissen "Einschaltzeit" aktiv werden sollte gibt es anacron
Hans Ulli Kroll schrieb: > Bei sleep sind auch diese Ungenauigkeiten, es soll ja wenigsten die > angegebene Zeit gewartet werden und nicht genau. Ich hatte mich auf das shell-sleep bezogen. Das Problem ist mittlerweile wohl als Fehler anerkannt und ist in Arbeit.
Gast
#3075068
Uhu Uhuhu schrieb: > Ich hatte mich auf das shell-sleep bezogen. Das Problem ist mittlerweile > wohl als Fehler anerkannt und ist in Arbeit. Anderes habe ich auch nicht erwartet. sleep von der Shell ruft ja auch nur sleep von libc auf. In der uClibc wird hier dann nanosleep aufgerufen.
Hans Ulli Kroll schrieb: > sleep von der Shell ruft ja auch nur sleep von libc auf. > In der uClibc wird hier dann nanosleep aufgerufen. Das Verhalten mag für die sleep-Funktion in der Bibliothek tolerierbar sein, für ein sleep auf Shell-Ebene ist es das im allgemeinen nicht und das sehen die coreutils-Entwickler mittlerweile auch so. Es wird wohl eine Option geben, die dafür sorgt, daß suspend-Zeiten berücksichtigt werden.