|
Bugzilla – Full Text Bug Listing |
| Summary: | pkexec crashes X session | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 12.2 | Reporter: | Dominique Leuenberger <dimstar> |
| Component: | Basesystem | Assignee: | Frederic Crozat <fcrozat> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Critical | ||
| Priority: | P5 - None | CC: | aj, badshah400, damianatorrpm, fcrozat, ismail, kukuk |
| Version: | Factory | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
/var/log/messages
messages - for another failure dmesg output with lots of systemd debug... |
||
|
Description
Dominique Leuenberger
2012-06-30 12:25:57 UTC
I actually just see that this is also the cause for another issue I've seen lately: when on Battery, and the notebook is not touched for a while, the 'screen dim' would kick in... in this moment, though, X resets... in /var/log/messages, you can find: Jul 3 00:20:51 laran pkexec[9674]: dle1gis: Executing command [USER=root] [TTY=unknown] [CWD=/home/dle1gis] [COMMAND=/usr/lib/gnome-settings-daemon-3.0/gsd-backlight -helper --set-brightness 4] I'm pretty sure this is recent, and given the lack of changes in polkit since February (if we except the packaging fix a few weeks ago), I doubt that polkit itself is the root cause. In the past, such issues were either caused by bugs in the pam module from systemd (iirc) and/or glibc bugs. Andreas: how did people find the cause of previous issues? Was there some specific log file that helped? I don't remember how people figured it out. For this case, I would look at * dmesg output: you should see a message like: [23634.779115] packagekitd[538]: segfault at e6a88 ip 00007fc42c051938 sp 00007fc427768ae0 error 6 in libzypp.so.1003.1.5[7fc42bc61000+4ca000] And this show which program is killed. * attach gdb to the X server before running pkexec and check the backtrace. Let's add Frederic since this really looks similar to our pam/systemd issue - and I've CC'ed myself to check glibc as well ;) Dominique, we need more debugging from you. Dominique, what's the output of "grep systemd /etc/pam.d/*" ? Btw. I just tried to run "pkexec /sbin/yast2" on my i686 system from the gnome-terminal, was asked for the root password and had a ncurses yast running afterwards. So, no problems on that system. to get more debug info, try to boot with "systemd.log_level=debug systemd.log_target=kmsg" + add "debug=1" to pam_systemd line in /etc/pam.d/common-session and when it crashes, check dmesg and /var/log/messages (In reply to comment #4) > Dominique, what's the output of "grep systemd /etc/pam.d/*" ? /etc/pam.d/common-session:session optional pam_systemd.so /etc/pam.d/common-session-pc:session optional pam_systemd.so (In reply to comment #5) > to get more debug info, try to boot with "systemd.log_level=debug > systemd.log_target=kmsg" + add "debug=1" to pam_systemd line in > /etc/pam.d/common-session > > and when it crashes, check dmesg and /var/log/messages How great is that! Simply adding debug=1 to pam_systemd.so in common-session is sufficient to not trigger the crash. Can you still reproduce it if you remove the debug=1 line? Might be a Heisenbug. ;-( I could only trigger it once - with a broken pam config. The contents from comment#6 looks fine. Frederic, will you take the bug? Or whom shall we blame? ;) No, currently I can't reproduce it... all what I actually did was: modified /etc/pam.d/common-session and added debug=1 to the line with pam_systemd.so... saved, logged out, back in (to enable the new 'session'). pkexec no longer crashes... removed the debug=1 again from the file... logged out / back in.. no crash.. reboot.. still not crash... so yes, 'on my system' it is apparently solved... but should we trust it? Really not sure what to say now.. I'll monitor it a bit more.. the most common 'way' it happened for me was while being on battery, leaving the system untouched for a while, then the screen dim kicks in (ising pkexec) and it brought me back to gdm. I'd suggest to let debug=1, in the case it crashes in the future. If it is similar to previous "sudo / pam_systemd" bug, it might happens only after several pkexec calls or maybe when calling sudo (or su) and then pkexec (but I'm just guessing) Just got locked out - Frederic, looks really like your bug, look at the the pkexec invocations below, I'm attaching a bit more of the log file. Jul 5 09:52:35 byrd pkexec: pam_systemd(polkit-1:session): Asking logind to create session: uid=659 pid=28721 service=polkit-1 type=unspecified seat= vtnr=0 tty= display= remote=no remote_user= remote_host= Jul 5 09:52:35 byrd pkexec: pam_systemd(polkit-1:session): Failed to create session: No such file or directory Jul 5 09:52:36 byrd pkexec[28721]: aj: Executing command [USER=root] [TTY=/dev/pts/10] [CWD=/home/aj/build/osc-branches/home:a_jaeger:devel-glibc/glibc] [COMMAND=/sbin/yast2] Jul 5 09:56:15 byrd dbus-daemon[698]: **** Refreshing ATA SMART data for /sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda Jul 5 09:56:15 byrd dbus-daemon[698]: helper(pid 28866): launched job udisks-helper-ata-smart-collect on /dev/sda Jul 5 09:56:15 byrd dbus-daemon[698]: **** Refreshing ATA SMART data for /sys/devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sdb Jul 5 09:56:15 byrd dbus-daemon[698]: helper(pid 28867): launched job udisks-helper-ata-smart-collect on /dev/sdb Jul 5 09:56:15 byrd dbus-daemon[698]: helper(pid 28867): completed with exit code 0 Jul 5 09:56:15 byrd dbus-daemon[698]: **** EMITTING CHANGED for /sys/devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sdb Jul 5 09:56:15 byrd dbus-daemon[698]: helper(pid 28866): completed with exit code 0 Jul 5 09:56:15 byrd dbus-daemon[698]: **** EMITTING CHANGED for /sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda Jul 5 09:57:29 byrd polkitd(authority=local): Operator of unix-session:/org/freedesktop/ConsoleKit/Session1 successfully authenticated as unix-user:root to gain ONE-SHOT authorization for action org.freedesktop.policykit.exec for unix-process:5242:11258 [/bin/bash] (owned by unix-user:aj) Jul 5 09:57:29 byrd pkexec: pam_systemd(polkit-1:session): Asking logind to create session: uid=659 pid=28928 service=polkit-1 type=unspecified seat= vtnr=0 tty= display= remote=no remote_user= remote_host= Jul 5 09:57:29 byrd pkexec: pam_systemd(polkit-1:session): Reply from logind: id=1 object_path=/org/freedesktop/login1/session/1 runtime_path=/run/user/aj session_fd=10 seat=seat0 vtnr=7 Jul 5 09:57:29 byrd pkexec[28928]: aj: Executing command [USER=root] [TTY=/dev/pts/11] [CWD=/home/aj/build/glibc/testing] [COMMAND=/sbin/yast2] Jul 5 09:57:29 byrd systemd-logind[16194]: Removed session 1. Jul 5 09:57:29 byrd kdm: :0[4587]: pam_systemd(xdm:session): Failed to release session: No such file or directory Jul 5 09:57:30 byrd kdm: :0[4587]: pam_close_session() failed: Cannot make/remove an entry for the specified session Created attachment 497471 [details]
/var/log/messages
Created attachment 497472 [details]
messages - for another failure
This time it I got kicked out directly after log in.
Created attachment 497474 [details]
dmesg output with lots of systemd debug...
I've been able to reproduce the issue by using this test scenario (works in a text tty or a graphical session): - login - run "sudo /bin/ls" or "su -c /bin/ls" - run "pkexec /bin/ls" => logout it is probably caused by pam_systemd being called in sudo / su (due to their pam configuration calling common-session pam configuration). Fedora is making sure to not include common-session in their sudo / su configuration. I wonder if we should do the same (because there is no new audit session created when running su / sudo and logind is relying on those audit session to "terminate" or not a session, when exiting) ? Let's include Thorsten to help with pam configuration (Thorsten see comment #15). common-session is important for su/sudo, especially if you don't want to manually sync all changes to the su/sudo config files. If, then the bug is that pam_systemd cannot be called from everything and should not be added to common-session. ok, let me see how to change the pam-config patch I wrote for systemd long time ago so it write the change in specific pam configuration (not ideal, because it will require to have a list somewhere). Or I try to patch pam_systemd to "detect" su/sudo and not do anything in this particular case (not pretty either). This is an autogenerated message for OBS integration: This bug (769531) was mentioned in https://build.opensuse.org/request/show/127853 Factory / systemd Hi, I tried to rebuild the systemd package with the login-logout patch enabled, it build successfully, I installed it and have no issues with pkexec. Is there any way I can get the automatic multiseat support working with 12.2? Cheers, Damian no, I won't enable this patch for 12.2 (it is not in Fedora17 either). And this patch is orthogonal to multiseat (which this bug is not about). Closing as fixed then. |