Ubuntu-Forum & Kubuntu-Forum | www.Ubuntu-Forum.de

Könnte es vielleicht sein, dass in meiner etc/init.d/halt etwas nicht stimmt??

Habe das Skript hier eingefügt

#! /bin/sh
### BEGIN INIT INFO
# Provides: halt
# Required-Start: umountroot
# Required-Stop:
# Should-Start: lvm raid2
# Should-Stop:
# Default-Start: 0
# Default-Stop:
# Short-Description: Execute the halt command.
# Description:
### END INIT INFO

PATH=/usr/sbin:/usr/bin:/sbin:/bin
[ -f /etc/default/halt ] && . /etc/default/halt

. /lib/lsb/init-functions

do_stop () {
if [ "$INIT_HALT" = "" ]
then
case "$HALT" in
[Pp]*)
INIT_HALT=POWEROFF
;;
[Hh]*)
INIT_HALT=HALT
;;
*)
INIT_HALT=POWEROFF
;;
esac
fi

# See if we need to cut the power.
if [ "$INIT_HALT" = "POWEROFF" ] && [ -x /etc/init.d/ups-monitor ]
then
/etc/init.d/ups-monitor poweroff
fi

# Don't shut down drives if we're using RAID.
hddown="-h"
if grep -qs '^md.*active' /proc/mdstat
then
hddown=""
fi

# If INIT_HALT=HALT don't poweroff.
poweroff="-p"
if [ "$INIT_HALT" = "HALT" ]
then
poweroff=""
fi

log_action_msg "Will now halt"
sleep 1
halt -d -f -i $poweroff $hddown
}

case "$1" in
start)
# No-op
;;
restart|reload|force-reload)
echo "Error: argument '$1' not supported" >&2
exit 3
;;
stop)
do_stop
;;
*)
echo "Usage: $0 start|stop" >&2
exit 3
;;
esac

:

Könnte mi vielleicht jemand, bei dem sich der rechner (automatisch) ausschalten lässt mal seine /etc/init.d/halt hier einfügen.

Ich benutze Feisty Fawn mit Kde

Meine Datei ist identisch.
Wenn Du nicht gerade selber an dem Script herumgebastelt hast, hätte mich das auch gewundert, wenn es irgendwie daran liegt.

ist das dann schlecht wenn ich andauerdn den ausschalter benutz um den rechner auszuschalten

Na, man kann's zwar vielleicht nicht gerade gut nennen, allerdings m.E. nicht so schlecht, dass Du Dir deshalb große Sorgen machen solltest
Ich hab's allerdings damals als furchtbar lästig empfunden aber ja schon seit einiger Zeit (wie schon beschrieben) keinerlei Probleme mehr damit :-)
Nach meiner Erfahrung lösen sich viele Probleme auch durch etwas Geduld

Hi

Zitat

Original von wowi
Nach meiner Erfahrung lösen sich viele Probleme auch durch etwas Geduld

Da hat er Recht der wowi. Allerdings sollte man die Selbstheilungskräfte von PCs nicht überschätzen...

Greetz Bluegrass

Ich würde zumindest vorher dafür sorgen, daß sämtliche Programme/Dienste geschlossen werden.

@magiceye04

Das hat damit wenig zutun sondern es liegt in FGLRX bzw ATI Karten - Treibern seitdem ich Upgrade habe von ATI nach Nvidia ist das Problem nicht mehr vorhanden sogar Gnome sieht jetzt G0IL aus mit Nvidia

Greetz

Hi

erst mal Hallo, ich bin, wie man sieht neu hier im Forum.

Ich habe hier das gleiche Problem, mittlerweile habe ich auf 4 Rechnern von SuSE 10.1 auf kubuntu feisty gewechselt. Seit dem fahren einige nicht mehr ganz runter.

Folgende Konstellationen:

Feity Installationen:
Dell Inspirion Notebook - fährt 'meist' runter.
Intel PIII 800MHz / Nvidia Karte - fährt immer runter.
AMD Athlon 64 X2 Dual Core Processor 4200+ mit Nvidia Karte - fährt nie richtig runter
AMD Athlon 2000+ mit Nvidia Karte - fährt nie richtig runter

Andere Distrys:
Intel PIII 500MHz SuSE 10.1 - fährt immer runter.
Intel PIII 1000MHz SuSE debian lenny als VDR (2.6.16) 10.1 - fährt immer runter.

Somit habe ich nur eine Feity Installation welche zuverlässig runter fährt.
Leider wäre das 'Runterfahren' gerade bei den beiden Athlon praktisch, da sie außer dem Notebook die einzigen sind die nicht ohnehin immer an sind.

In den Athlon ist ein ASRock Bord, hat das ggf. damit was zu tun? Oder gibt es den für fglrx beschriebenen Effekt auch mit Nvidia-Karten wobei ich auf den beiden Athlon nur den nv Treiber verwende da der nvidia dort nicht zum laufen zu bewegen ist (anderes Problem)?

Ich habe auch bereits versucht von ACPI auf APM umzusteigen das scheint aber im Kununtu Kernel nicht drin zu sein. Auch sollte m.E. mindestens der sehr neue Athlon Dual Core ACPI unterstützen, oder?


Es scheint auch nicht am ausschalten (ACPI) zu liegen ich glaube eher das da ein Treiber oder Dienst hängenbleibt da man, egal wie lange man wartet bevor man 'hart' ausschaltet beim nächsten booten das Filesystem prüfen darf!

Es macht auch keinen Unterschied wie man runterfährt, poweroff, shutdown -h now, via KDE, ... immer das gleiche Ergebnis.

Grüße und Danke für jeden Tipp
horchi

keiner eine Idee?

Hallo horchi!

Guckst Du mal in unsere Regeln!

Pushen von Beiträgen ist nicht erlaubt!!

Greetz Bluegrass

Tja, ich bin auch ein leidtragender von diesem Thema und wollte meinen nichts beitragenden Text loslassen, der auch eine kleinen Portion Frust enthält.

Ich habe auch sämtliche Foren durchforstet , Google gequält und ausgesaugt und einige Linuxvollchecker genervt, bis auch diese aufgegeben haben. Alle Lösungsvorschläge ausprobiert und nichts ändert sich.

Interesannterweise fährt mein Laptop mit Gentoo sauber runter und, man stelle sich vor, es geht aus, so richtig aus. Gentoo ist ansich ein cooles System, aber für mich nicht geeignet auf einem Laptop für daheim.

Mit Fedora (5, 6 und 7 kann ich erst gar nicht installieren *g*) hab ich auch das gleiche Problem, nur mit dem Unterschied, dass es mal geht, mal nicht.

Mit Ubuntu geht es halt permanent nicht.

Irgendwie ist das alles sehr, sehr komisch.

Meine Hardware:

LG LW20 - Pentium M 2 GHz - 12.1" TFT
Eingebaute Geräte Stereo-Lautsprecher, drahtlose LAN-Antenne
Prozessor Intel Pentium M 2 GHz
Cache-Speicher 2 MB - L2
RAM 512 MB DDR II SDRAM - 533 MHz
Kartenleser 4-in-1
Festplatte 60 GB
Optische Speicher DVD±RW (+R Double Layer) / DVD-RAM
Display 12.1" TFT-Aktivmatrix 1280 x 800 ( WXGA )
Grafik-Controller Intel GMA 900
Audioausgang Soundkarte
Telekommunikation Fax / Modem - 56 Kbps
Netzwerk Netzwerkkarte - Ethernet, Fast Ethernet, IEEE 802.11b, IEEE 802.11a, IEEE 802.11g
Wireless NIC Intel PRO/Wireless 2915ABG

Hi,

ich habe den shutdown auf meinen Systemen nun endlich in den Griff bekommen . War ein langes mühseliges suchen in den Init-Skripten.

Es hatte bei mir zwei Ursachen:

Zum einen hängt das dbus Init-Skript beim runterfahren (auf meinen im obigen Post als 'fährt nie richtig runter' gekennzeichneten System) immer, da konnte ich bislang nur umgehen indem ich es beim Runterfahren ganz aus den Runleveln genommen habe. ist nicht DIE Lösung aber geht. Vieleicht gibt es dafür ja irgendwann mal ein Fix .....

Zum anderen ist das Skript umountnfs.sh zu weit hinten in der Init Kette.War auf Position K40 ich habe es nun auf K15 verschoben, jedenfalls VOR das runterfahren der Netzwerkschnittstellen. Nun bleibt auch das nicht mehr hängen und die Rechner fahren fein runter und schalten sich ab

Vieleicht hilft es ja noch wem.

Grüße
horchi

dbus? Init Kette?

Kannst Du das vielleicht nocheinmal etwas ausführicher beschreiben, so verstehe ich es leider nicht und ich würde gerne etwas dazu lernen!

Hi barbex,

Zitat

Original von barbex
dbus? Init Kette?
Kannst Du das vielleicht nocheinmal etwas ausführicher beschreiben, so verstehe ich es leider nicht und ich würde gerne etwas dazu lernen!

Ja, gern, mit Init Kette meine ich die Reihenfolge in welcher die Init-Skripte (beim Hoch- bzw. Runterfahren) via der Links in den Runlevel Verzeichnissen aufgerufen werden.

Hier ist es, wenn ich nichts übersehe, m.E. suboptimal NFS-Mounts nach dem beenden der Netzwerkinterfaces auszuhängen (umounten) da dies in der Regel zu einem ewigen Timeout führt (bei mir Stunden). Warum dies bei kununtu so gelöst ist, keine Ahnung, vermutlich ein Bug, habe ich noch bei keiner anderen Distri. so gesehen.

Daher habe ich dies mit den folgenden Kommandos geradegezogen:


das war jedoch nur die erste Hürde, nun hing er (bei mir) im dbus Skript, auch hier vermute ich, dass es an der Reihenfolge liegt. Da das aber aus meiner Sicht nicht so kritisch ist habe ich bei mir einfach die ../K... Links gelöscht statt die richtige Stelle zu suchen. Das will ich so nun aussitzen bis hoffentlich dazu ein Fix veröffentlicht wird

Das entfernen der dbus Links geht mit



Achtung, dabei nur die K-Links löschen, die S sind zu hochfahren und werden benötigt!

Ob das auch bei dir das Problem löst, keine Ahnung. Für das NICHT-Runterfahren von kubuntu gibt es ja (wie man auch in diesen Thread sieht) mannigfaltige Ursachen

Grüße
horchi

Seufz...

Das ist eindeutig alles zu hoch für mich.

Zitat

Original von barbex
Seufz...

Das ist eindeutig alles zu hoch für mich.

Hi,

In diesem Ordner findest du eine kleine Doku zu den Runleveln, den Skripten und deren Aufrufreihenfolge. Vieleicht hilft das etwas weiter.

/usr/share/doc/sysv-rc/

Grüße
horchi