• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Abmeldung mittels Strg Alt Entf

OP
A

Anonymous

Gast
Nein, mit Dialog; habe wieder alles zurück gestellt, wie es standardmäßig war.
Keine Netzwerke, keine zusätzlichen Geräte, nichts.

Bei plasma wird meist der Desktop dann quasi ausgeblendet.
Genau das (abgedunkelte/grau werdende Bild) dauert 30 Sekunden, dann geht es Comp auch aus. Und das ging beim Anklicken von "Herunterfahren" (als Beispiel) vorher sofort aus, ohne die zeitliche Verzögerung.
 

revealed

Guru
Hallo.

Du schaltest das in dem Menü, '$ kcmshell5 kcmsmserver' dem Kcontrol-module ganz ab mit der Option:
[] Abmeldung bestätigen
Also Haken raus.

Wenn wir den drin liessen, dann würde der Dialog auf unsere Eingabe max. 30 Sekunden warten. Aber das schalten wir ja ab. Sodass er gleich mit dem Beenden loslegt.

Was dann noch kommt:

Wenns dann noch dauert, blockiert eine noch laufende Anwendung. Da sind dann noch fest eingebaut gewisse timeouts festgelegt. Auf die haben wir so ohne weiteres keinen Einfluss. Den Anwendungen werden Signale vom System gesendet, dass sie jetzt bitte Feierabend machen sollen. Eines reagiert dann vermutlich nicht, oder kann nicht beendet werden.

Also in systemd ist crtl alt del ein symlink. Schätzungweise ist der maskiert (schau mal):
Code:
ls -al /usr/lib/systemd/system | grep reboot.target
Der zeigt dann irgendwie auf reboot.target.

Nachdem du das drückst, wird dem System ganz normal der Befehl zum herunterfahren gegeben.

Gruß,

R
 
OP
A

Anonymous

Gast
Jetzt haste mich richtig verstanden
Wenn wir den drin liessen, dann würde der Dialog auf unsere Eingabe max. 30 Sekunden warten.

Genau das will ich ja auch so lassen/haben; nur: Wenn ich den Knopf Herunterfahren klicke (oder welche Ooptin mir auch immer dort angezeigt wird ...), in diesem geöffneten Dialogfenster, dann dauert es ab dem "klick" immer noch 30 Sekunden. Vorher war das so, dass dann dieser "Count-Down" abgebrochen und das System sofort heruntergefahren wurde. Und das bekomme ich mit keiner Einstellung wieder hin, bzw. kann es nicht ändern. Das ist seit einigen Wochen so, habe schon (fast) alles durchprobiert.
 

revealed

Guru
Hast mal im journal geschaut was da so lange benötigt?
Code:
journalctl -b -1 | egrep "SIGTERM|SIGRTMIN"
Vielleicht macht uns das schlau. Sollte ja zeitlich abgestuft sein.

K.a. evtl hast ja ne riesen lücke zu networkmanager oder so... ?

Gruß,

R
 
OP
A

Anonymous

Gast
Code:
Passwort: 
linux-bmws:~ # ls -al /usr/lib/systemd/system | grep reboot.target
lrwxrwxrwx 1 root root    13 Mar 18 11:58 ctrl-alt-del.target -> reboot.target
-rw-r--r-- 1 root root   493 Feb 25 21:11 reboot.target
drwxr-xr-x 1 root root   118 Mar 18 11:58 reboot.target.wants
lrwxrwxrwx 1 root root    13 Mar 18 11:58 runlevel6.target -> reboot.target
linux-bmws:~ #

Code:
linux-bmws:~ # journalctl -b -1 | egrep "SIGTERM|SIGRTMIN"
Dec 26 17:33:20 linux-bmws avahi-daemon[869]: Got SIGTERM, quitting.
Dec 26 17:33:53 linux-bmws sddm[1124]: Signal received: SIGTERM
linux-bmws:~ #

?? Kannst du damit etwas anfangen ?? (was will's denn nun mit Weihnachten ...?)
 

revealed

Guru
Mal also su oder root oder su -c oder sudo den journal befehl noch bitte. Wenn dein user nicht in der entsprechenden Gruppe 'systemd-journal' ist, kann er nicht alle Logeinträge abfragen.

Gruß,

R
 
OP
A

Anonymous

Gast
Schaut für mich gleich aus, ich gehe immer mit sudo in die Konsole ...

Code:
linux-bmws:~ # sudo journalctl -b -1 | egrep "SIGTERM|SIGRTMIN"
Dec 26 17:33:20 linux-bmws avahi-daemon[869]: Got SIGTERM, quitting.
Dec 26 17:33:53 linux-bmws sddm[1124]: Signal received: SIGTERM
linux-bmws:~ #
 
OP
A

Anonymous

Gast
Sry - eben erst gesehen

K.a. evtl hast ja ne riesen lücke zu networkmanager oder so... ?
Da ist bei mir nichts zu finden :???: Jedenfalls nicht in der Leiste unten, oder im KickOff.
 

revealed

Guru
Mir wird schlecht von systemd, wenn ich die manpage lese und es nicht geht. Kannst das bitte als root ausführen?
Code:
journalctl -b -1 | egrep "SIGTERM|SIGRTMIN"

Gruß,

R

PS.: Mein systembenutzer ist in der entsprechenden Gruppe und das hier sollte das normal anzeigen, tuts aber nicht. Macht freilig kein Spass so.

Komisch auf einmal geht der doch bei mir:
Code:
su -c 'journalctl -b -1 | egrep "SIGTERM|SIGRTMIN"'
Im zweiten versuch geht das auch auf einmal:
Code:
sudo journalctl -b -1 | egrep "SIGTERM|SIGRTMIN"
Is ja egal, machs bitte kurz als root.
 
OP
A

Anonymous

Gast
Sieht nicht vielversprechender aus

Code:
Passwort: 
linux-bmws:~ # sudo journalctl -b -1 | egrep "SIGTERM|SIGRTMIN"
Dec 26 17:33:20 linux-bmws avahi-daemon[869]: Got SIGTERM, quitting.
Dec 26 17:33:53 linux-bmws sddm[1124]: Signal received: SIGTERM

linux-bmws:~ # journalctl -b -1 | egrep "SIGTERM|SIGRTMIN"
Dec 26 17:33:20 linux-bmws avahi-daemon[869]: Got SIGTERM, quitting.
Dec 26 17:33:53 linux-bmws sddm[1124]: Signal received: SIGTERM
linux-bmws:~ #
 
OP
A

Anonymous

Gast
Habs mir angesehen, verstehe das auch nicht.
Blöde Frage: Kann das mit den sn snapshots zusammenhängen? Dort habe ich vor einigen Tagen mal aufgeräumt, und die Alten alle gelöscht.

Code:
Passwort: 
linux-bmws:~ # snapper list
Type   | #    | Pre # | Date                     | User | Cleanup | Description       | Userdata     
-------+------+-------+--------------------------+------+---------+-------------------+--------------
single | 0    |       |                          | root |         | current           |              
single | 890  |       | Thu Mar  3 13:25:20 2016 | root |         |                   |              
pre    | 946  |       | Tue Apr 12 11:56:31 2016 | root | number  | zypp(packagekitd) | important=yes
pre    | 947  |       | Tue Apr 12 12:40:25 2016 | root | number  | zypp(packagekitd) | important=yes
pre    | 952  |       | Tue Apr 12 14:25:04 2016 | root | number  | zypp(packagekitd) | important=yes
post   | 953  | 952   | Tue Apr 12 14:30:00 2016 | root | number  |                   | important=yes
pre    | 999  |       | Mon Apr 18 23:34:18 2016 | root | number  | yast snapper      |              
single | 1000 |       | Mon Apr 18 23:36:22 2016 | root |         | april             |              
post   | 1001 | 999   | Mon Apr 18 23:36:33 2016 | root | number  |                   |              
pre    | 1002 |       | Mon Apr 18 23:36:39 2016 | root | number  | yast snapper      |              
post   | 1003 | 1002  | Mon Apr 18 23:37:21 2016 | root | number  |                   |              
pre    | 1004 |       | Tue Apr 19 11:29:57 2016 | root | number  | zypp(packagekitd) | important=no 
post   | 1005 | 1004  | Tue Apr 19 11:30:18 2016 | root | number  |                   | important=no 
pre    | 1006 |       | Tue Apr 19 12:25:35 2016 | root | number  | zypp(packagekitd) | important=no 
post   | 1007 | 1006  | Tue Apr 19 12:26:02 2016 | root | number  |                   | important=no 
linux-bmws:~ #


Bin dann mal wesch, bis heute Abend.
 

revealed

Guru
Kannst ja mal versuchen ob balance was hilft.
Code:
btrfs fi balance start / -dusage=5

Da gings nur drum dass die Platte voll war, oder?

Du wirst ja schätzungsweise die tools verwendet haben die man dazu nimmt.
Code:
snapper -c root list
snapper -c root delete #
Und dann die config noch n bissl eingestellt haben.

Hast du evtl n haufen coredumps?
Code:
du -hs /var/lib/systemd/coredump
Wenn das Verzeichnis recht voll ist, wäre das ein Indikator für häufige Abstürze. (Die sterben oft auch erst, wenn man sie beendet).

Gruß,

R
 

revealed

Guru
Oder benutz einen pasteservice wegs der Übersicht und leite die Ausgabe von so einem fehlerfall shutdown in eine Textdatei um und poste diese oder so. Vielleicht sieht man was in der Gänze.
Code:
journalctl -b -1 > /tmp/test.txt;

und dann... k.a. sprunge pastebin oder so...

Eh und kein networkmanager zu finden... könntest mal schauen ob es sich ändert wenn du die Methode zum steuern vom Netzwerk im yast netzwerkmodul auf networkmanager umstellst.

Evtl doch das Netzwerk? K.a. wie ich da jetz drauf komm...

Gruß,

R
 
OP
A

Anonymous

Gast
Also, schau mal hier

Code:
Passwort: 
linux-bmws:~ # btrfs fi balance start / -dusage=5
Done, had to relocate 0 out of 37 chunks
linux-bmws:~ #

Code:
Passwort: 
linux-bmws:~ # du -hs /var/lib/systemd/coredump
0       /var/lib/systemd/coredump

linux-bmws:~ # journalctl -b -1 > /tmp/test.txt;
linux-bmws:~ # ^C
linux-bmws:~ #

im yast netzwerkmodul auf networkmanager umstellst.

Im YaST unter Netzwerkdienste stand, wenn das Fenster öffnet und die Konfig geladen [xinetd] hat "Konfiguration der Netzwerkdienste deaktiviert (xinetd)" - was mich verwundert, wieso deaktiviert?? Habe es nun mal umgestellt (aktiviert) und starte die Möhre mal neu ...
 

revealed

Guru
Ok, nein nicht da.
Code:
su -c 'yast2 lan'
Bei globale Optionen. "Methode für den Netzwerkaufbau". Wähle networkmanager, falls dort wicked eingestellt ist.

Ja und den Inhalt aus der "/tmp/test.txt" dann bitte über so eine Pastewebseite hierher verlinken.

... xinetd ist was anderes. Wenn du meinst, dass du das brauchst evtl wegen cups oder so. Dann machs an. Da wollte ich nich hin mit dir eigentlich.

Gruß,

R
 
OP
A

Anonymous

Gast
Wenn ich YaST 2 lan via Konsole öffne, dann erscheint dort im Fenster als angezeigter Adapter

Code:
MCP61 Ethernet 
MAC : ***************
BusID : 0000:00:07.0

Device Name: eth0
Started automatically at boot
IP address assigned using DHCP

An den Einstellungen dort habe ich nichts verändert, da ich davon ausgehe dass du nicht diese Lan-Einstellungen meinstest!?
xinetd habe ich wieder wie vorher auf deaktiviert gestellt. CUPS brauche ich nicht für meinen USB-Drucker (denke ich mal).
Jedenfalls funzt der gut, auch Dank diesem Forum :)
 
OP
A

Anonymous

Gast
/tmp/test.txt http://paste.opensuse.org/88563aa1
(hat etwas gedauert, war am Essen) :D

Der Screenshot von dir schaut bei mir ganz anders aus ... ganz anders :???:
http://paste.opensuse.org/77577a3f
 

revealed

Guru
noreset -displayfd 18 vt7
Dec 26 17:33:21 linux-bmws wickedd-dhcp4[980]: eth0: Request to release DHCPv4 lease with UUID 187d7e56-bab7-0000-d703-000004000000
Dec 26 17:33:22 linux-bmws wickedd-dhcp6[979]: eth0: no lease set
Dec 26 17:33:22 linux-bmws wicked[10455]: eth0 device-ready
Dec 26 17:33:23 linux-bmws sddm[1124]: Running display setup script "/etc/X11/xdm/Xsetup"
Dec 26 17:33:25 linux-bmws display-manager[10377]: Shutting down service sddm..done
Dec 26 17:33:53 linux-bmws sddm[1124]: Display server started.

Dec 26 17:33:53 linux-bmws sddm[1124]: Socket server starting...
Dec 26 17:33:53 linux-bmws sddm[1124]: Socket server started.
Dec 26 17:33:53 linux-bmws sddm[1124]: Greeter starting...
Sieht mir ziemlich nach dem timeout aus den du beschreibst. Sieht aber auch so aus als würde SDDM bei dir mal öfter crashen.

Wasn das hier? Ist ja übelst der SPAM:
Code:
Dec 26 17:22:10 linux-bmws ntfs-3g[4112]: [123B blob data]

Da hängt irgendwas beim beenden von SDDM:
Dec 26 17:33:53 linux-bmws sddm[1124]: QProcess: Destroyed while process ("/usr/lib/sddm/sddm-helper") is still running.



Gruß,

R
 
Oben