Re: Friert systemd-logind oder etwas anderes inaktive Desktop-Sitzungen ein?
On Samstag, 27. Februar 2016 09:37:45 CET Michael Schuerig wrote:
> On Friday 26 February 2016 11:25:36 Martin Steigerwald wrote:
> > On Mittwoch, 24. Februar 2016 17:33:14 CET Martin Steigerwald wrote:
> > > Hallo!
> > >
> > > Ich hab oft zwei Plasma-Sitzungen. Eine auf VT7 und eine auf VT8.
> > >
> > > Oft verwende ich für eine Stunde oder mehr nur eine einzige
> > > Plasma-Sitzung.
> > >
> > > Jetzt hatte ich aber mehrfach den Eindruck, dass die gerade nicht
> > > verwendete Sitzung auch pausiert war (beispielsweise via freezer
> > > cgroup, was weiß ich), denn ich ich dann zurückwechselte, war die
> > > Anzeige noch genau so, wie vorher und erst dann lief z.B.
> > > kdesrc-build weiter, kamen Benachrichtungen oder griff die
> > > Energieverwaltung. Mit der Energieverwaltung ist das besonders
> > > merkwürdig: Die dunkelt dann erst den Bildschirm ab und macht ihn
> > > dann gleich wieder hell.
> >
> > Eine weitere Beobachtung: Wenn ich eine der beiden Sitzungen beendet
> > und dann sofort mit Strg-Alt-F7 z.B. auf die andere wechsele, dann
> > bleibt die Sitzung stehen, bis ich nochmal mit Strg-Alt-F8 auf die
> > beendete wechsele und abwarte bis sie heruntergefahren ist. Und das
> > inklusive eines laufenden von Network Manager initialisierten
> > OpenVPN-Tunnel.
> >
> > Das Verhalten ist so kaputt, dass mir die Worte dafür fehlen.
>
> Kannst du nicht sehen, was die Prozesse aus der anderen Session machen?
> Einfach mit top müsste doch erkennbar sein, ob da nur Stillstand ist.
> Oder mit strace. Die Sessions sind doch bestimmt nicht so gut von
> einander isoliert, dass du da als root nicht raus kämst.
Genau das habe ich vor, zu tun. Aber fürs Wochenende wollte ich Pause davon haben.
Also übe ich mich darin, jetzt erstmal nicht zu wissen, was da genau los ist.
Ich wollte mit ps aux nach dem Prozess-Status schauen und auch schauen,
inwiefern ich die Prozesse in der cgroup-Hierarchie, die systemd da aufbaut,
und die ich noch nicht so ganz checke, wieder finde. Nur falls die Prozesse
auf Ein-/Ausgabe warten, nicht Massenspeicher, da wäre es dann der Status
"D", sondern Bildschirm, dann weiß ich nicht genau, woran ich das sehen
kann.
Okay, jetzt hab ich doch geschaut, da ich die zweite Sitzung heute eh
nochmal brauche:
1) Ich hab mir das nicht eingebildet, das Perl-Skript kdesrc-build bleibt
z.B. tatsächlich stehen. Allerdings laufen die angestarteten Compiler- oder
sonstigen Prozesse noch zu Ende. kdesrc-build startet nur keine neuen mehr,
*bis* ich wieder auf die Sitzung zurückschalte, dann läuft es weiter, als wäre
nichts gewesen.
2) Eingefroren werden Prozesse nicht, ein stress -c 1 läuft ungehindert weiter.
Es gibt auch keine Untergruppe in der Freezer-CGroup-Hierarchie.
3) Aus der CGroup-Geschichte sehe ich gerade keinen Grund für das Anhalten.
4) Und auch ansonsten weiß ich nicht genau, warum kdesrc-build stoppt.
Hier folgt, was ich versucht habe:
ms@merkaba:~> date; pstree -p | grep kdesrc-build
Sa 27. Feb 11:37:47 CET 2016
| |-zsh(12400)---perl(15783)-+-kdesrc-build-up(15842)-+-git(26231)
| | | `-kdesrc-build-mo(15843)
[…]
ms@merkaba:~> date; pstree -p | grep kdesrc-build
Sa 27. Feb 11:38:16 CET 2016
| |-zsh(12400)---perl(26547)-+-kdesrc-build-up(26603)---kdesrc-build-mo(26604)
Da baut der noch was.
ms@merkaba:~> ps aux | head -1 ; ps aux | grep "[2]6604"
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
ms@merkaba:~#1> date; pstree -p | grep kdesrc-build
Sa 27. Feb 11:38:57 CET 2016
| |-zsh(12400)---perl(26547)-+-kdesrc-build-up(26603)
Jetzt nicht mehr.
ms@merkaba:~> date; pstree -p | grep kdesrc-build
Sa 27. Feb 11:39:11 CET 2016
| |-zsh(12400)---perl(26547)-+-kdesrc-build-up(26603)
Eltern-Prozess reagiert nix:
ms@merkaba:~> ps aux | head -1 ; ps aux | grep "[2]6603"
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
martin 26603 1.7 0.0 0 0 pts/2 ZN+ 11:37 0:01 [kdesrc-build-up] <defunct>
ms@merkaba:~>
Daher:
merkaba:/sys/fs/cgroup> ps aux | grep "[Z]N+"
martin 26603 0.8 0.0 0 0 pts/2 ZN+ 11:37 0:01 [kdesrc-build-up] <defunct>
martin 30486 0.0 0.0 0 0 pts/2 ZN+ 11:38 0:00 [make] <defunct>
Hier pstree:
|-konsole(12291)-+-zsh(12294)---su(12839)---zsh(12840)
| |-zsh(12400)---perl(26547)-+-kdesrc-build-up(26603)
| | `-make(30486)
Hier meine Analyse der Cgroup:
merkaba:/sys/fs/cgroup> for T in $( find -name "tasks" ) ; do if grep 30486 $T; then echo "gefunden in $T" ; fi ; done
merkaba:/sys/fs/cgroup> for T in $( find -name "tasks" ) ; do if grep 26603 $T; then echo "gefunden in $T" ; fi ; done
Okay, die sind ja im Prinzip schon weg.
merkaba:/sys/fs/cgroup> for T in $( find -name "tasks" ) ; do if grep 26547 $T; then echo "gefunden in $T" ; fi ; done
26547
gefunden in ./cpuset/tasks
26547
gefunden in ./cpu,cpuacct/user.slice/user-1000.slice/tasks
26547
gefunden in ./memory/user.slice/user-1000.slice/tasks
26547
gefunden in ./freezer/tasks
26547
gefunden in ./blkio/user.slice/user-1000.slice/tasks
26547
gefunden in ./perf_event/tasks
26547
gefunden in ./pids/user.slice/user-1000.slice/session-5.scope/tasks
26547
gefunden in ./net_cls,net_prio/tasks
26547
gefunden in ./devices/user.slice/user-1000.slice/tasks
26547
gefunden in ./systemd/user.slice/user-1000.slice/session-5.scope/tasks
Sehe keinen Grund für ein Einfrieren hier in den Control Groups.
In freezer ist die PID nur in der obersten Hierarchie, wo alle Prozesse
drin sind.
ms@merkaba:~> ps aux | head -1 ; ps aux | grep "[2]6547"
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
martin 26547 0.1 0.1 73824 26168 pts/2 SN+ 11:37 0:00 perl ./kdesrc-build
S interruptible sleep (waiting for an event to complete)
N low-priority (nice to other users)
+ is in the foreground process group
Hmmm, auf irgendetwas wartet er.
Nur was?
ms@merkaba:~> ps -eo pid,cmd,sched,sess,sig,sigcatch,sigignore,sigmask,wchan,nwchan | head -1 ; ps -eo pid,cmd,sched,sess,sig,sigcatch,sigignore,sigmask,wchan,nwchan | grep "[2]6547"
PID CMD SCH SESS PENDING CAUGHT IGNORED BLOCKED WCHAN WCHAN
26547 perl ./kdesrc-build 0 12400 0000000000000000 0000000180005027 0000000000000080 0000000000000000 - -
Keine Ahnung.
Irgendeine Idee, wie ich das ausfinde?
Ich könnte natürlich versuchen, rechtzeitig ein strace dran zu hängen.
Irgendeine andere Idee?
Ich habs jetzt noch nicht ausprobiert, aber meine bisherige Beobachtung war,
dass das auch mit anderen Bau-Prozessen ist, wie beispielsweise make-kpkg.
Kann ich natürlich auch nochmal verifizieren.
Und auch sonst kommen nach dem Umschalten nochmal alle Benachrichtungen
von zwischen durch (das ergibt ja noch einen gewissen Sinn), oder eben dieses
merkwürdige Ergebnisse, dass die Sitzung nicht mal komplett runterfährt, wenn
ich vorher auf die andere Sitzung schalte.
Ciao,
--
Martin
Reply to: