Problem runter-/hochfahren

Lieber Besucher, herzlich willkommen bei: GentooForum.de. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

Niualj

Fortgeschrittener

Beiträge: 224

13.05.2016, 16:05

Problem runter-/hochfahren

In letzter zeit ist es mir öfters passiert, dass mein System während des runter und hochfahrens anhält, bzw. ewig braucht:

Beim Runterfahren sagt er mir immer so ungefähr "a shutdown job is running [5s/3min]"
und wartet dann bis er nach 3 Minuten den Prozess immer noch nicht beenden konnte.

Beim Hochfahren ist es mir besonders aufgefallen, wenn ich das Lankabel (Laptop) beim start eingesteckt habe,
dass es dann ewig dauert und im 800x600 Modus endet statt 1366x768.

Das seltsame ist, das beides (zum Glück) nicht immer passiert.
Nun ist meine Frage, wo ich als erstes suchen sollte.

python -c "import this"

def is_nerd(): while coding:
if inside.has_fun: return True
else return False

Zum Seitenanfang

sdoubleyou

Schüler

Beiträge: 103

13.05.2016, 17:47

Ich gehe jetzt einfach mal davon aus, dass du systemd nutzt,
Leider kommt es da immer wieder mal zu diesen unerklärlichen Problemen mit den "A stop job is running vor C1 (oder user xvy)"
Du wirst da auch nicht viel finden. Evtl. kannst du einmal mit

	Quellcode
1	loginctl session-status

oder mit

	Quellcode
1	journalctl -xf

etwas herauslesen.
Persönlich hatte ich einmal die Erfahrung damit unter Arch bei einer Kombi conky/dezn2 bei der Wlan-Überwachung gemacht bzw. wenn eine ntfs-USB-Platte nicht sauber mit umount ausgehängt hatte. (sind aber nur Beispiele, gibt genug andere zu dem Thema)

Zum Thema hier ein immer noch nicht gelöster Bugreport: https://bugs.freedesktop.org/show_bug.cgi?id=70593
Ein weiteren Ansatz könnte helfen, wenn Du mal versuchst die Zeiten dafür herabzusetzen in der

	Quellcode
1	/etc/systemd/system.conf

und dort die Bereiche

	Quellcode
1 2	#DefaultTimeoutStartSec=90s #DefaultTimeoutStopSec=90s

	Quellcode
1 2	DefaultTimeoutStartSec=10s DefaultTimeoutStopSec=10s

zu ändern. In der heutigen Zeit sollte das ausreichen.
Ob das was bringt ist zu überprüfen. Ich hatte es damals nicht umgesetzt bzw. getestet.

Zur 2. Frage
hast du evtl. eine interne GraKa und nutzt eine zweite bzw. eine Hybrid-Karte? Das könnte evtl. ein Ansatz sein

Solltest du kein systemd einsetzen, vergiss das alles hier

Zum Seitenanfang

Niualj

Fortgeschrittener

Beiträge: 224

13.05.2016, 18:57

nur mal so nebenbei, welche Vorteile/Nachteile habe ich denn bei systemd oder OpenRc?

hier mal die Ausgaben fals mir jemand helfen kann beim rauslesen:

Quellcode

root# loginctl session-status
1 - julian (1000)
           Since: Fr 2016-05-13 15:50:48 CEST; 3h 5min ago
          Leader: 4168 (sddm-helper)
            Seat: seat0; vc1
         Display: :0
         Service: sddm; type x11; class user
           State: active
            Unit: session-1.scope
                  ├─ 4168 /usr/libexec/sddm-helper --socket /tmp/sddm-auth9a4d2d63-e1fe-42dc-b67c-313c7f921fa1 --id 1 --start startlxqt --user julian
                  ├─ 4173 lxqt-session
                  ├─ 4181 dbus-launch --autolaunch 36b6a3e51a84223922cb028c553a887d --binary-syntax --close-stderr
                  ├─ 4182 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
                  ├─ 4189 /usr/bin/dbus-launch --sh-syntax --exit-with-session
                  ├─ 4190 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 15 --session
                  ├─ 4203 kwin_x11
                  ├─ 4212 /usr/bin/kactivitymanagerd start-daemon
                  ├─ 4216 /usr/bin/kglobalaccel5
                  ├─ 4224 /usr/bin/xcompmgr
                  ├─ 4226 python2.7 /usr/bin/hp-systray -x
                  ├─ 4234 /usr/bin/python2.7 /usr/share/system-config-printer/applet.py
                  ├─ 4235 pcmanfm-qt --desktop --profile=lxqt
                  ├─ 4236 lxqt-globalkeysd
                  ├─ 4237 lxqt-notificationd
                  ├─ 4238 lxqt-panel
                  ├─ 4239 lxqt-policykit-agent
                  ├─ 4240 lxqt-runner
                  ├─ 4242 /usr/bin/xscreensaver -no-splash
                  ├─ 4249 /usr/bin/nm-applet
                  ├─ 4259 /usr/bin/pulseaudio --start --log-target=syslog
                  ├─ 4268 /usr/libexec/menu-cache/menu-cached /tmp/.menu-cached-:0-julian
                  ├─ 4273 /usr/libexec/gvfsd
                  ├─ 4294 /usr/libexec/gvfs-udisks2-volume-monitor
                  ├─ 4295 NetworkManager
                  ├─ 4298 /usr/libexec/at-spi-bus-launcher
                  ├─ 4317 /usr/bin/dbus-daemon --config-file=/etc/at-spi2/accessibility.conf --nofork --print-address 3
                  ├─ 4321 /usr/libexec/at-spi2-registryd --use-gnome-session
                  ├─ 4324 /usr/bin/python2.7 /usr/share/system-config-printer/scp-dbus-service.py
                  ├─ 4327 /usr/libexec/gvfsd-trash --spawner :1.14 /org/gtk/gvfs/exec_spaw/0                                                                                                
                  ├─ 4354 python2.7 /usr/bin/hp-systray -x                                                                                                                                  
                  ├─ 4355 python2.7 /usr/bin/hp-systray -x                                                                                                                                  
                  ├─ 4383 lxqt-powermanagement                                                                                                                                              
                  ├─ 4614 /usr/libexec/gconfd-2                                                                                                                                             
                  ├─ 4967 /usr/bin/yakuake                                                                                                                                                  
                  ├─ 4971 kdeinit4: kdeinit4 Runnin e                                                                                                                                       
                  ├─ 4973 kdeinit4: klauncher [kdei e                                                                                                                                       
                  ├─ 4975 kdeinit4: kded4 [kdeinit]                                                                                                                                         
                  ├─ 4984 /usr/bin/knotify4
#hier kamen nur noch die Fenster die ich gerade auf hatte

Ich habe eine interne (nicht hybrid Graphikkarte von intel (total simpel

))

python -c "import this"

def is_nerd(): while coding:
if inside.has_fun: return True
else return False

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Niualj« (13.05.2016, 19:07)

Zum Seitenanfang

sdoubleyou

Schüler

Beiträge: 103

13.05.2016, 20:23

ich sagte ja, du wirst nichts finden ;-)

es ist halt ein Bug in systemd.

Zitat von »Niualj«

nur mal so nebenbei, welche Vorteile/Nachteile habe ich denn bei systemd oder OpenRc?

Vorteile? Ich kenne keine. Bin deshalb ja auch jetzt vor geraumer Zeit von Arch zu Gentoo gewechselt. In anderen Foren würde jetzt bestimmt auch ein extreme Stressdiskussion entstehen (gehe ich zumindest von aus) Kann Dir nur meine persönliche Meinung zu dem Thema sagen.

Damals hatten ja alle gesagt, hui - schnelles starten -alles wird einfacher. Schon vor der Einführung gab es ja kontroverse Diskussionen.

Das größte Manko ist eben (meine Meinung!), dass systemd sich immer mehr Kerntechnologien zu Eigen gemacht hat wie z.B. dbus und udev. Was aktuell noch viel schlimmer ist, dass Entwickler bzw. auch die Benutzer in Ihrer Wahl der Werkzeuge nicht frei sind, sondern immer weiter eingeschränkt werden und genau das spricht eben gegen die Idee der Free / Open Source-Software.

In einem Interview von 2012, hat der Slackware-Gründer Patrick Volkerding seine Bedenken über die systemd Architektur geäußert. Dort hat er mal gesagt, dass er im Bezug auf systemd die Idee gut findet eine schnellere Boot-Zeit zu erhalten, aber auch die Steuerung der Inbetriebnahme des Systems mit Shell-Skripten, die lesbar sind.

Trotzdem haben alle Hurra geschrien. Das Fedora das einführen musste, war ja klar. Aber das fast alle anderen dem Trugschluss - jetzt wird alles Einfacher und Schneller - Glauben geschenkt haben?

Persönlich geht mir die Bootzeit wenig ab, ob ich 2 ms länger brauche oder nicht, ich boote mein System nicht mehrmals am Tag!

Was mir persönlich viel schlimmer abgeht ist die Entwicklung um systemd herum. Der "Rote Hut" bietet keine 32-bit-Version mehr an! Andere Distributionen, die auf systemd gewechselt sind (auch Sabayon) auch nicht mehr. Es ist wieder ein Baustein der Macht, die systemd-Entwickler aufbauen. "Wir unterstützen das nicht mehr und somit friss oder stirb". Gummiboot soll in systemd integriert werden! Also UEFI nur mit systemd, oder?

Will ja nicht unken, aber in geraumer Zeit kommt dann noch "Du möchtest systemd?" Na klar, aber nicht mehr ohne SELinux!

Viele haben zwar kein System aus Redmond, aber bald sehr sehr viel aus Raleigh

Zu openRC
OpenRC ist halt ein abhängigkeitsbasierendes RC-System, welches unabhängig vom System bereitgestellten init funktioniert. (wenn ich es richtig verstanden habe)

OpenRC bietet u.a. folgende Funktionen:
- Portable auf Nicht-Linux-Systeme
- paralleler Start von Diensten
- abhängigkeitsbasierend beim Boot-Up
- Trennung der Prozesse durch Kontrollgruppen
- Per-Service-Ressourcen-Limits (ulimit)
- Trennung von Code und Konfiguration (init.d / conf.d)
- Leicht erweiterbare Startskripts, vom Nutzer individuell definierbar
- Die Fähigkeit, eine unbegrenzte Anzahl von grundlegenden Befehlen über einfache "Start, Stop und Status-Befehle" auszuführen
- Stateful Init-Skripte (es ist bereits gestartet?)
- Komplexe Init-Skripte, um mehrere Komponenten (samba (smbd und nmbd), NFS (nfsd, portmap usw. starten)
- Automatische Abhängigkeitsberechnungen und Bereitstellung der notwendigen Services
- Die richtige Integration & Virtualisierung (Linux-VServer, OpenVZ, etc.)
- Die richtige modulare Architektur und die Trennung von optionalen Komponenten (cron, Syslog)
- flexibles handling der Netzwerke (einschließlich VPN, Bridge, etc.)
- Ein ausführlicher Debug-Modus!!

Persönlich arbeite ich jetzt sehr gerne mit openRC, weil es mir die Möglichkeit gibt Dienste in verschiedenen sog. Run-Level zu setzen. Brauch ich sie zum Systemstart, dann in default, brauch ich sie zur Laufzeit dann eben in einen anderen Level. Belastet das mein System? Ich glaube nicht. Was noch viel besser ist, nur die Skripte aus /etc/init.d, die es ausführen soll, werden auch ausgeführt. Welche das sind, steht in /etc/runlevels und das alles in Klarschrift und es unterliegt alles dem Willen des Users!

Openrc gibt mir die Freiheit bestimmte Dinge selber zu entscheiden. Leider ist das Problem, dass systemd immer tiefer eingreift, weil eben andere Pakete sonst nicht mehr funktionieren. Der Zug ist evtl. nicht aufzuhalten aber eine gewisse Zeche werden wir alle gemeinsam zahlen.

Zum Seitenanfang

Niualj

Fortgeschrittener

Beiträge: 224

14.05.2016, 15:03

Welchen unterschied macht den openrc beim konfigurieren?
Also muss man mehr zeit einplanen, und wenn ja wieviel mehr?
Ich meine einmal zum aufbauen und dann zu warten.

Und ich habe eins nicht ganz verstanden:

Zitat

dass systemd sich immer mehr Kerntechnologien zu Eigen gemacht hat wie z.B. dbus und udev. Was aktuell noch viel schlimmer ist, dass Entwickler bzw. auch die Benutzer in Ihrer Wahl der Werkzeuge nicht frei sind

Was ist gemeint mit zu Eigen machen? Das man es nurnoch mit systemd verwenden kann?
Und welche Werkzeuge kann man sich nicht auswählen?

python -c "import this"

def is_nerd(): while coding:
if inside.has_fun: return True
else return False

Zum Seitenanfang

Niualj

Fortgeschrittener

Beiträge: 224

14.05.2016, 22:40

Jetzt verstehe ich auch wieso ich ab Ubuntu 15.04 immer Probleme hatte, weshalb ich ja auch zu Gentoo gewechselt bin.
Ab da hat nämlich Ubuntu systemd verwendet.

Ich denke systemd ist auch nichts ganz schlechtes, es hat auch ein paar Vorteile und man sollte nicht immer gleich schwarz sehen.
Interessant finde ich aber dennoch das uselessd, was aus systemd wieder ein normales init-System bauen wollte.
Schade, dass nur eine einzelne Person daran gearbeitet hat.

Ich denke ich muss also vorerst mit den shutdown Problemen zurecht kommen, was auch nicht das Problem ist, weil ich durchschnittlich 1 mal pro Tag runterfahre, und da kann sich der PC dann auch Zeit lassen.

python -c "import this"

def is_nerd(): while coding:
if inside.has_fun: return True
else return False

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Niualj« (14.05.2016, 22:48)

Zum Seitenanfang

michi-monster

Fortgeschrittener

Beiträge: 250

16.05.2016, 15:14

@sdoubleyou : danke für die tolle Erläuterung.

Mein Veto gegen systemd liegt in der ausführlichen Konfiguration . Leider geht es nicht mehr ohne (?) .... Ich musste einsehen, auch wenn ich nur fluxbox nutze, irgendwann ein Paket systemd braucht. OpenRC kam mir stabiler vor. Was aber auch daran liegen kann, dass ich mit systemd wie gesagt, einige Probs habe. Die Umstellung habe ich erstmal aufgegeben. Bin gerade dabei nach wiki systemd zu installieren.

Zitat

Ich meine einmal zum aufbauen und dann zu warten.

der Aufbau bzw. auch die Umstellung nimmt viele Sachen in Anspruch. Daduch, dass öfter Konflikte enstehen ist eine höhere Wartung erforderlich. Sobald udev und systemd irgendwo in Konflikt geraten, was leider noch häufig der Fall ist, müssen Aktionen eingeleitet werden.

EDIT: ja, leider ein udev / systemd Fehler. Habe einen eigenen Thread erstellt.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »michi-monster« (16.05.2016, 17:34)

Zum Seitenanfang

Niualj

Fortgeschrittener

Beiträge: 224

16.05.2016, 20:13

Vielleicht sind ein paar weniger Fehler, wenn ich auch nach der Anleitung systemd reinstalliere.

python -c "import this"

def is_nerd(): while coding:
if inside.has_fun: return True
else return False

Zum Seitenanfang

sdoubleyou

Schüler

Beiträge: 103

16.05.2016, 21:10

Zitat von »michi-monster«

Leider geht es nicht mehr ohne (?) .... Ich musste einsehen, auch wenn ich nur fluxbox nutze, irgendwann ein Paket systemd braucht. OpenRC kam mir stabiler vor.

Ich nutze spectrwm und wüsste nicht, dass es ein Paket gibt, welches systemd benötigt. Auch fluxbox geht sauber ohne systemd.

Zum Seitenanfang

Niualj

Fortgeschrittener

Beiträge: 224

17.05.2016, 07:24

Nur eins möchte ich noch dazu sagen:
Mein Bruder ist jetzt zu Windoof gewechselt, nachdem sein PC (mit systemd!) beim starten dauernd Probleme machte,
teilweise "viel schneller startete als sonst (10 Minuten startzeit)" und einige andere dinge nicht mehr so liefen, wie er braucht
um vernünftig arbeiten zu können.
Ich weiß nicht aber BSD nutzt systemd ja nicht, ich önnte mir vorstellen, dass einige der Desktop User jetzt zu BSD wechseln.

python -c "import this"

def is_nerd(): while coding:
if inside.has_fun: return True
else return False

Zum Seitenanfang

nisto

Anfänger

Beiträge: 28

17.05.2016, 11:28

Zitat von »sdoubleyou«

Zitat von »michi-monster«

Leider geht es nicht mehr ohne (?) .... Ich musste einsehen, auch wenn ich nur fluxbox nutze, irgendwann ein Paket systemd braucht. OpenRC kam mir stabiler vor.

Ich nutze spectrwm und wüsste nicht, dass es ein Paket gibt, welches systemd benötigt. Auch fluxbox geht sauber ohne systemd.

Ich nutze fluxbox ohne systemd, läuft prima.

Zum Seitenanfang

michi-monster

Fortgeschrittener

Beiträge: 250

17.05.2016, 16:34

fluxbox selbst läuft. Ich habe im Moment ein simples Problem: Die Schrift ist zu klein. Laut Info soll es mit sandr richtig eingestellt werden können. Bei Eingabe des Befehls kommt allerdings no display found. xorg und fluxbox sind installiert. Dadurch, dass ein Update mit dem udev/systemd Problem geblockt wird, habe ich da im Moment aber nicht weitergemacht. Vielleicht könnt ihr mir aber den ersten Schritt geben. xrandr - display not found - what can i do