ubuntuusers.de

Hi,

meine anacron jobs werden nicht gestartet, weil init() den prozess nach dem start gleich wieder killt. Steht ja auch so in /var/log/syslog

Habt ihr Ähnliches? Was kann der Grund sein?

xubuntu 9.10

/var/log/syslog

...
Oct 19 22:28:19 kk-box anacron[1152]: Anacron 2.3 started on 2009-10-19
Oct 19 22:28:19 kk-box cron[1138]: (CRON) INFO (pidfile fd = 3)
Oct 19 22:28:19 kk-box cron[1164]: (CRON) STARTUP (fork ok)
Oct 19 22:28:19 kk-box anacron[1152]: Will run job `cron.daily' in 5 min.
Oct 19 22:28:19 kk-box anacron[1152]: Will run job `cron.weekly' in 10 min.
Oct 19 22:28:19 kk-box anacron[1152]: Jobs will be executed sequentially

...
Oct 19 22:28:34 kk-box init: anacron main process (1152) killed by TERM signal

"sudo anacron" geht

Danke esk

bei mir auch. Vielleicht ist es dieser fehler
https://bugs.launchpad.net/ubuntu/+source/anacron/+bug/411796
ich stells in /etc/cron.d/anacron einfach mal von 7 auf 19 Uhr täglich, wenns dann immer noch klemmt auf stündlich.

Same here. Mit Ubuntu 9.10.

sudo start anacron

funktioniert und läuft dann auch durch. Wie kann man denn herausfinden, was wer wann wo und weshalb anacron wieder beendet? Ich hab das Gefühl, dass es upstart selber ist, welches anacron einfach wieder stoppt.

Ich habe exakt dasselbe Problem. Siehe http://forum.ubuntuusers.de/topic/anacron-startet-nicht/

Mein System wird nicht schlafen gelegt, sondern abends richtig runter- und morgens wieder hochgefahren, es hat also nichts mit fehlerhaften Suspend/Resume-Routinen zu tun.

Es betrifft wohl auch noch andere Benutzer: http://swiss.ubuntuforums.org/showthread.php?t=1335531

Ich hatte genau das gleiche Problem und habe es folgendermaßen gelöst:

der init daeomon startet u.a. ein Script namens /etc/rc2.d/S99acpi-support. Dieses Script wiederum startet ein Script /etc/acpi/power.sh welches seinerseits pm-powersave startet. Hierbei handelt es sich ganz offensichtlich um ein Programm, das den Computer in einen "low power mode" versetzt. Üblicherweise tut er das um die Lebensdauer des Laptop Akkus zu verlängern. Warum dieses Programm allerdings glaubt, die Lebensdauer des nicht vorhandenen Akkus in meinem Desktop-PC verlängern zu müssen, habe ich auch noch nicht herausgefunden.

Laut manpage führt dieses Programm alle Skripte in den Verzeichnissen /etc/pm/power.d/ und /usr/lib/pm-utils/power.d/ aus. Und siehe da, in letzterem Verzeichnis gibt es ein Script namens anacron, das im "Low power mode" "stop -q anacron" aufruft, d.h. anacron wieder abschießt. Desweiteren erklärt die manpage, dass die Scripte in /etc/pm/power.d/ Vorrang haben und dass im Falle gleichnamiger Scripte in beiden Verzeichnissen nur das in /etc/pm/power.d/ ausgeführt wird. Ich habe also einfach ein "leeres" Script namens "anacron" in /etc/pm/power.d/ angelegt und siehe da, anacron wird beim Systemstart nicht mehr abgeschossen.

gnafets: Danke! Darauf wäre ich nicht so schnell gekommen. Damit läuft anacron beim Systemstart schon mal los und erledigt die anstehenden Arbeiten. Allerdings wird anacron immer noch nach dem ersten Lauf nach dem Systemstart beendet. Unter Hardy lief anacron dagegen noch als eigener Dienst weiter, neben cron. Ich würde jetzt nur noch gerne wissen, ob das eine gewollte Änderung ist, oder ob es noch einen weiteren ungewollten Grund gibt, warum anacron nicht weiterläuft.

Eine gewollte Änderung kann ich verstehen: denn wenn anacron nach dem Systemstart seine Arbeit verrichtet hat, können alle anderen regelmäßigen Arbeiten bis zum nächsten Aus- und wieder Einschalten von cron übernommen werden.

AAABER!! Dann darf /etc/crontab aber nicht so aussehen, wie sie nach der Installation aussieht:

# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.

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

# m h dom mon dow user  command
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
#

Denn die Tatsache, daß ein ausführbares Binary /usr/sbin/anacron existiert, sagt ja nichts darüber aus, ob es auch aktiv ist. Wenn also das Abschalten des Dienstes anacron nach dessen ersten Lauf gewollt ist, müßte die /etc/crontab entsprechend anders aussehen.

Oder habe ich da jetzt einen Denkfehler?

Nachtrag: ich habe jetzt einfach mal ein "apt-get remove --purge laptop-mode-tools" ausgeführt. Das hat dann auch gleich das Pakete "acpi-support*" entfernt. mal sehen, was morgen beim Start passiert.

Ich denke die Art und Weise wie anacron gestartet und nach Erledigung seiner Aufgaben wieder gestoppt wird, ist schon beabsichtigt. Mit Karmic hat sich u.a. der init daemon geändert. Dieser startet Dienste nicht mehr in Abhängigkeit vom Run-Level sondern Event gesteuert. So wird anacron z.B. nicht mehr über /etc/init.d/anacron gestartet, sondern es gibt ein Konfigurationsfile namens anacron.conf unter /etc/init:

# anacron - anac(h)ronistic cron
#
# anacron executes commands at specific periods, but does not assume that
# the machine is running continuously

description	"anac(h)ronistic cron"

start on runlevel [2345]
stop on runlevel [!2345]

expect fork
normal exit 0

exec anacron -s

Daran erkennt man zum einen, dass init durchaus erwartet, dass sich anacron regulär beendet (normal exit 0) und zum anderen nicht wieder gestartet werden soll, wenn er nicht regulär beendet wird (kein respawn Kommando).

Bleibt die Frage, wie anacron wieder gestartet wird, wenn der Rechner durchläuft: In diesem Fall muss anacron von cron gestartet werden, das passiert aber nicht durch /etc/crontab sondern durch /etc/cron.d.

Was ich noch nicht so ganz durchschaut habe: warum verhält sich acpi-support unter Karmic anders als unter den Vorgängerversionen? Vielleicht hat da ja jemand eine Idee!

Viele Grüße Stefan

gnafets schrieb:

Ich denke die Art und Weise wie anacron gestartet und nach Erledigung seiner Aufgaben wieder gestoppt wird, ist schon beabsichtigt. Mit Karmic hat sich u.a. der init daemon geändert. Dieser startet Dienste nicht mehr in Abhängigkeit vom Run-Level sondern Event gesteuert. So wird anacron z.B. nicht mehr über /etc/init.d/anacron gestartet, sondern es gibt ein Konfigurationsfile namens anacron.conf unter /etc/init: ...

Ist ja auch sehr sinnvoll, denn wenn die Maschine durchgehend läuft, ist anacron unnötig.

Bleibt die Frage, wie anacron wieder gestartet wird, wenn der Rechner durchläuft: In diesem Fall muss anacron von cron gestartet werden, das passiert aber nicht durch /etc/crontab sondern durch /etc/cron.d.

Stimmt, jetzt, da Du es sagst... 😀 (Siehe /etc/cron.d/anacron)

Was ich noch nicht so ganz durchschaut habe: warum verhält sich acpi-support unter Karmic anders als unter den Vorgängerversionen? Vielleicht hat da ja jemand eine Idee!

Ich kann mal eine wilde Vermutung anstellen: die Autoren von acpi-support und/oder die Jungs und Mädels von Canonical haben versucht, Karmic so gut es geht an mobile Rechner anzupassen und deren Benutzer eine möglichst lange Akkulaufzeit zu spendieren. In einem der Kommentare der beteiligten Dateien steht etwas darüber. Und ich vermute, daß bei dieser Anpassung an mobile Geräte einfach einiges "verschlimmbessert" wurde, was (manche) Benutzer von nicht-mobilen Rechnern dann zu spüren bekommen.

Im Editorial der aktuellen Ausgabe des Magazins "LinuxUser"¹ schreibt der Chefredakteur Jörg Luther, daß Ubuntu Karmic stark den Eindruck erwecke, unter sehr großem Druck und mit sehr heißer Nadel gestrickt worden zu sein. Diesen Worten kann ich mich nach all den Erfahrungen, die ich beim Umstieg bisher erlebt habe, und nach all den Problemen, über die ich bisher gelesen habe, nur anschließen.

¹ http://www.linux-community.de/Internal/Artikel/Print-Artikel/LinuxUser/2009/12/Ubuntu-11

Unter Kubuntu 9.10 stelle ich folgende Situation fest:

Zunächst wird anacron gestartet. Der Login-Dialog erscheint. Ich warte. Einige Sekunden später startet die "Skript-Kette", so wie von gnafets einige Posts zuvor beschrieben. Anacron wird beendet.

Wenn ich mich aber beim Login-Dialog beeile und somit die KDE-Sitzung also recht früh startet, dann wird anacron nicht beendet. Grund:

Teil der Skrip-Kette ist eine Funktion aus der Datei /usr/share/acpi-support/policy-funcs:

CheckPolicy() {
	local PMS
	PMS="gnome-power-manager kpowersave xfce4-power-manager"
	PMS="$PMS guidance-power-manager.py dalston-power-applet"
	if pidof -x $PMS > /dev/null ||
	   (pidof dcopserver > /dev/null && test -x /usr/bin/dcop && /usr/bin/dcop kded kded loadedModules | grep -q klaptopdaemon) ||
	   PowerDevilRunning ; then
		echo 0;
	else
		echo 1;
	fi
}

PowerDevilRunning() {
	test -x /usr/bin/dbus-send || return 1
	
	for p in $(pidof kded4); do
		test -r /proc/$p/environ || continue
		local DBUS_SESS=$(cat /proc/$p/environ | grep -z "DBUS_SESSION_BUS_ADDRESS=")
		test "$DBUS_SESS" != "" || continue
		(su - $(ps -o user= $p) -c "$DBUS_SESS dbus-send --print-reply --dest=org.kde.kded /kded org.kde.kded.loadedModules" | grep -q powerdevil) && return 0
	done
	
	return 1
}

Für KDE4-Systeme ist nun die Funktion PowerDevilRunning ausschlaggebend. Wird der "PowerDevil" erkannt, so wird "0" zurückgegeben und anacron wird nicht beendet. Das Problem ist hier also, dass PowerDevil oft nicht rechtzeitig "läuft". Ich lasse den Rechner oft ne Weile am Login-Dialog "warten", weil ich noch andere Dinge erledige...

Ganz schlecht sieht es aus, wenn man den KDE-Dienst "PowerDevil" komplett deaktviert. Dabei ist das naheliegend, da dieser in der Oberfläche als "Energieverwaltungsdienst für Notebooks" angepriesen wird. Na dann, ich habe ja gar kein Notebook...

Aaaah! Das erklärt auch ein anderes Phänomen: ich erhalte manchmal vom System (cron) eine e-mail mit folgendem Inhalt:

start: Job is already running: anacron

Bisher konnte ich mir das nicht erklären, weil ich bisher keine Regelmäßigkeit erkannt habe. Jetzt, da Du es erwähnst, fällt es mir aber wie Schuppen aus den Haaren: diese Nachricht kriege ich immer dann, wenn ich mich nicht sofort nach dem Start des Rechners an KDE anmelde, sondern etwas später.

Interessanter Hinweis, danke!