staging.inyokaproject.org

rc.local wird nicht ausgeführt?

Status: Ungelöst | Ubuntu-Version: Xubuntu 14.04 (Trusty Tahr)
Antworten |

kay94

Anmeldungsdatum:
12. Februar 2013

Beiträge: 106

Hi,

ich verwende Xubuntu 14.04 und habe irgendwie den Verdacht, dass meine rc.local nicht ausgeführt wird. Im Artikel zur rc.local steht:

Ab Ubuntu 14.10 muss die Ausführung der Datei /etc/rc.local aufgrund des neuen Init-Systems systemd erst aktiviert werden.

Sollte ich jetzt systemd haben, oder nicht? Nach meinem Verständnis käme 14.10 -nach- 14.04, oder zählt das als gleichzeitig? Jedenfalls habe ich probehalber das im Artikel zu systemd genannte "systemctl cat rc-local" ausgeführt, das schlägt fehl:

kay@kay-T430:~$ systemctl cat rc-local
systemctl: Befehl nicht gefunden.

Aber:

kay@kay-T430:~$ dpkg --get-selections | grep systemd
libpam-systemd:amd64				install
libsystemd-daemon0:amd64			install
libsystemd-login0:amd64				install
systemd-services				install
systemd-shim					install

Heißt doch, dass systemd installiert ist, oder? Ich kann leider nicht ausschließen, dass ich einmal vor längerer Zeit - fahre das System schon länger - ein "apt-get install systemd" gemacht habe, ohne zu wissen, was ich da eigentlich treibe, weil ich irgendwo irgendwas gelesen habe.

Sind jetzt alles nur Vermutungen, mit denen ich etwas Vorarbeit leisten wollte, bevor ich hier frage. Der eigentlich Anlass ist, dass diese Befehle, die ich in rc.local eingetragen habe scheinbar nicht ausgeführt werden:

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

echo 1 > /sys/devices/system/cpu/cpufreq/ondemand/ignore_nice_load
(/bin/sleep 20 && echo 2000000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq)
(/bin/sleep 20 && echo 2000000 > /sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq)
(/bin/sleep 20 && echo 2000000 > /sys/devices/system/cpu/cpu2/cpufreq/scaling_max_freq)
(/bin/sleep 20 && echo 2000000 > /sys/devices/system/cpu/cpu3/cpufreq/scaling_max_freq)

exit 0

Denn:

kay@kay-T430:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
3300000

Sieht jemand den Fehler? ☹

ChickenLipsRfun2eat Team-Icon

Anmeldungsdatum:
6. Dezember 2009

Beiträge: 12067

Ich erlaube mir einfach mal blöd zu fragen: Wird der Wert in der Datei denn von anderen Programmen überschrieben? Wenn ja, wieso machst du das nicht als cronjob?

Zum Test, ob die rc.local beim Systemstart ausgeführt wird, kannst du ja mal ein

echo "ich laufe" >> /home/DeinBenutzer/rclocal.txt

eintragen und gucken, ob es die Datei nach einem Neustart gibt.

kay94

(Themenstarter)

Anmeldungsdatum:
12. Februar 2013

Beiträge: 106

Gute Idee → rc.local wird bei mir definitiv nicht ausgeführt. Habe es gerade auch mit einem cron-Job versucht; kannte ich vorher gar nicht. Funktioniert allerdings auch nicht mit:

@reboot echo "hi" >> /home/kay/cron.txt

😕

Ich wüsste nicht, wer da noch was reinschreiben sollte... Wenn ich es nach dem Systemstart manuell mache, geht es aber. Ärgerlich ist, dass ich jetzt schon zwei Mal vergessen habe, BOINC anzuhalten, bevor ich reboote und mit rc.local etc. experimentiere und meine CPU dann wegen dem blöden TurboBoost auf 99°C hochgekocht ist. 😠

ChickenLipsRfun2eat Team-Icon

Anmeldungsdatum:
6. Dezember 2009

Beiträge: 12067

Also wenn ich crontab -e aufrufe und da

 */1 * * * * echo "hi" >> /home/koffeinfriedhof/cron.txt
 

eingebe, dann klappt das. Möglicherweise musst du dein @reboot etwas verzögern mit /bin/sleep 5 oder so.

Der nächste Test wäre dann einen prüfbaren Befehl als Service Unit einzurichten.

Wundert mich aber schon, dass du systemd hast. Kann es mangels Zugriff gerade nicht an meinem 14.04er testen. Aber ich meine, da läuft kein systemd...

lubux

Anmeldungsdatum:
21. November 2012

Beiträge: 14402

kay94 schrieb:

Gute Idee → rc.local wird bei mir definitiv nicht ausgeführt.

Versuch mal mit dem kompletten Pfad für echo und trage die Zeile, in der rc.local an der richtigen Stelle ein (wegen dem "-e" nach der shebang).

kay94

(Themenstarter)

Anmeldungsdatum:
12. Februar 2013

Beiträge: 106

@chickenLipsRfun2eat koffeinfriedhof? ersthaft? 😊 Habe cronjob jetzt dazu gebracht, ein Skript von mir auszuführen, das die benötigten Befehle beinhaltet. Allerdings dauert es mit vorangestelltem "/bin/sleep 10" über eine Minute, bis die Änderungen wirksam werden, was definitiv zu lang ist, um BOINC daran zu hindern, mir den Prozessor zu grillen. Habe auch versucht, BOINC dazu zu bewegen, erst nach einer gewissen Zeit loszulegen, was aber nicht klappt und möchte mich ehrlich gesagt auch nicht drauf verlassen müssen. Es lag wohl am Syntaxt, mit meinem @reboot, wie ich es im wiki-Artikel gelesen habe, hats nicht geklappt.

Für den Moment habe ich Intel SpeedStep ausgeschaltet, damit die CPU nicht über 1.2GHz kommt...

@lubux Danke für deinen Beitrag, verstehe aber ehrlich gesagt nicht genau, was ich machen soll. Kannst du das nochmal ein bisschen anders erklären? Wäre nett!

PS: Daran, dass das Forum die Zeilen nicht so macht, wie ich es beim Verfassen eingebe, werde ich mich wohl nie gewöhnen... ^^

lubux

Anmeldungsdatum:
21. November 2012

Beiträge: 14402

kay94 schrieb:

..., verstehe aber ehrlich gesagt nicht genau, was ich machen soll. Kannst du das nochmal ein bisschen anders erklären? >

Mit

which echo

schauen wie der komplette Pfad für echo ist und danach die "richtige" Zeile, (als 2. Zeile) unter der shebang-Zeile (#!/bin/sh -e) der rc.local-Datei eintragen und testen.

ChickenLipsRfun2eat Team-Icon

Anmeldungsdatum:
6. Dezember 2009

Beiträge: 12067

kay94 schrieb:

@chickenLipsRfun2eat koffeinfriedhof? ersthaft? 😊

Ja! Und der Name ist Programm ☺

kay94

(Themenstarter)

Anmeldungsdatum:
12. Februar 2013

Beiträge: 106

Okay, kleines Update:

mit /bin/echo hats auch in der rc.local funktioniert! Dann wollte ich mein kleines Script von dort aus starten, das ich ja zuerst für cronjob vorgesehen hatte, etwa so:

/home/kay/cpu_freq.sh

...hat aber gar nicht funktioniert. Ich musste die Datei ins root Verzeichnis schieben, vielleicht lags ja daran, dass root aktiv wurde, bevor ich mich angemeldet habe oder was auch immer, weiß ja nicht wie das im Hintergrund abläuft. Also jetzt meine rc.local:

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

/root/cpu_freq.sh

exit 0

cpu_freq.sh:

echo powersave > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo powersave > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
echo powersave > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor
echo powersave > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor

echo 2200000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo 2200000 > /sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq
echo 2200000 > /sys/devices/system/cpu/cpu2/cpufreq/scaling_max_freq
echo 2200000 > /sys/devices/system/cpu/cpu3/cpufreq/scaling_max_freq

(Als ausführbar markiert mit chmod 755 cpu_freq.sh) → Hier geht es komischerweise ohne explizites /bin/echo. Werde ich aber sicherheitshalber mal noch einfügen...

Ich bin dann einmal in den Ruhezustand gegangen, und beim wieder Hochfahren war "scaling_max_freq" nur noch für /cpu0 auf 2200000 gesetzt. Warum auch immer. Normalerweise wird die CPU dann dennoch global mit 2.2GHz gefahren, aber sicherheitshalber habe ich noch in /usr/lib/pm-utils/sleep.d/94cpufreq das markierte eingefügt (Vorraussetzung: sysfsutils ist installiert, siehe wiki-Artikel "Prozessortaktung", letzter Abschnitt):

#!/bin/sh
# Ensure cpu governor is set to something sane.
# TODO: Which of the cpu governors is still insane?  File bugs against
#       those that are.

. "${PM_FUNCTIONS}"

[ -d /sys/devices/system/cpu/ ] || exit $NA

hibernate_cpufreq()
{
	( cd /sys/devices/system/cpu/
	for x in cpu[0-9]*; do
		# if cpufreq is a symlink, it is handled by another cpu. Skip.
		[ -L "$x/cpufreq" ] && continue
		gov="$x/cpufreq/scaling_governor"
		# if we do not have a scaling_governor file, skip.
		[ -f "$gov" ] || continue
		# if our temporary governor is not available, skip.
		grep -q "$TEMPORARY_CPUFREQ_GOVERNOR" \
			"$x/cpufreq/scaling_available_governors" || continue
		savestate "${x}_governor" < "$gov"
		echo "$TEMPORARY_CPUFREQ_GOVERNOR" > "$gov"
	done )
}

thaw_cpufreq()
{
	( cd /sys/devices/system/cpu/
	for x in cpu[0-9]*/cpufreq/scaling_governor ; do
		[ -f "$x" ] || continue
		state_exists "${x%%/*}_governor" || continue
		restorestate "${x%%/*}_governor" > "$x"
	done )
}

case "$1" in
	suspend|hibernate)
		hibernate_cpufreq
		;;
	resume|thaw)
		thaw_cpufreq
		/root/cpu_freq.sh
		;;
	*) exit $NA
		;;
esac

Eigentlich wollte ich ursprünglich ja (siehe https://forum.ubuntuusers.de/topic/boinc-turboboost/), dass BOINC mit seiner hohen CPU-Last gar nicht erst dazu führt, dass der Takt rauf geht. Da das

http://wiki.ubuntuusers.de/Prozessortaktung#Prozessor-taktet-bei-unwichtigen-Prozessen-hoch

aber nicht funktioniert hat, geht jetzt halt der CPU-Takt nicht mehr über 2.2Ghz oder wie ichs auch einstelle... auch gut.

Letzte Frage die ich hier noch hätte:

Seid ihr der Meinung, dass noch irgendwas schief gehen könnte, abgesehen von dem Problem mit Ruhezustand, dass ja jetzt gelöst ist? Wäre sehr ärgerlich, wenn mein Rechner doch irgendwann mit Vollauslastung in den TurboBoost geht und ich nix davon merke... Danke soweit schonmal, hat echt geholfen!

Benno-007

Anmeldungsdatum:
28. August 2007

Beiträge: 29240

In ein verschlüsseltes Home kann die rc.local im gesperrten Zustand natürlich auch nicht schreiben. Und 20s warten je Kern ist auch ganz schön lang - Absicht gewesen?

kay94

(Themenstarter)

Anmeldungsdatum:
12. Februar 2013

Beiträge: 106

Ich wüsste nicht, dass mein /home verschlüsselt wäre.. ist schon lang her, dass ich das System aufgesetzt habe.

Ne, dass das dann 20s JE kern wartet, hatte ich verpeilt 😀 Aber ist ja auch schon draussen, siehe aktuellste Variante.

Benno-007

Anmeldungsdatum:
28. August 2007

Beiträge: 29240

mount|grep ecryptfs

zeigt Verschlüsselung an, sonst keine Ausgabe. Nur zum Verständnis.

lubux

Anmeldungsdatum:
21. November 2012

Beiträge: 14402

kay94 schrieb:

Ich wüsste nicht, dass mein /home verschlüsselt wäre..

Muss es ja auch nicht, für dieses Verhalten der rc.local. Bei der Ausführung aus der rc.local stehen nun mal unterschiedliche Umgebungen zur Verfügung, die man halt berücksichtigen soll/muss.

Max-Ulrich_Farber

Avatar von Max-Ulrich_Farber

Anmeldungsdatum:
23. Januar 2007

Beiträge: 8010

Jetzt hat's mich doch auch interessiert, ob /etc/rc.local mit systemd ausgeführt wird oder nicht.

Ergebnis: Auch in meinem Ubuntu 16.04 (Xenial) wird rc.local beim Systemstart anstandslos ausgeführt, ohne dass ich es irgendwie hätte aktivieren müssen.

Gruß – Max-Ulrich

Benno-007

Anmeldungsdatum:
28. August 2007

Beiträge: 29240

Dann war das vielleicht nur bei 15.10 so. Könnte man dann in etwa 4 Wochen streichen bzw. besser als optional manuell markieren, wenn 15.10 nun im Juli langsam ausläuft. Vorausgesetzt, bei den andren Flavours ist es auch so voreingestellt. Ich geb's weiter.

Antworten |