Bug 76765
| Summary: | sawfish can be used as a session killer | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Michal Jaegermann <michal> |
| Component: | sawfish | Assignee: | Havoc Pennington <hp> |
| Status: | CLOSED WONTFIX | QA Contact: | David Lawrence <dkl> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 8.0 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2003-01-12 23:04:53 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Perhaps a stuck server grab; if you kill sawfish or sawfish-ui, do things unfreeze? I don't understand the strace though. The tar process has exited, and then wait4() is called for the tar process, so wait4() should return immediately (I double-checked in the main page). > Perhaps a stuck server grab; if you kill sawfish or sawfish-ui, do things > unfreeze? That would be the first thing to try, wouldn't it? Unfortunately the answer is no. On one try I managed to get things back with 'killall gdm-binary'. More "delicate" attempts did not have any visible effect. On the other one things get so knotted that none of signals to any of session processes worked. It was kind of a strange as 'ps' did not show up any of these in "D" state but they were mostly (all?) "S". Still multiple attempts to kill with various signals were ineffective. Eventually I rebooted. Maybe 'telinit 1' would work too but I did not try. An error in a hindsight. > I don't understand the strace though. That makes two of us. :-) I was scratching my head about that as well. I hoped that you may know much more about possible internal interactions. I don't foresee being able to make progress on this. If we could come up with a smaller test case maybe the kernel guys could look at it. |
Description of Problem: Using sawfish-ui it is possible to lock the whole session in no time at all leaving only remote access alive. It is not necessary to play with fonts at all (I know that this is totally broken) but scanning through few themes seems to be enough. I am afraid that I do not have a recipe for that but few "natural" clicks here and there should to the job. Apparently relevant pieces from strace look like this (3068 is the main process of sawfish, 3121 is its forked child) ........ 3121 execve("/bin/tar", ["tar", "--version"], [/* 34 vars */]) = 0 3121 uname({sys="Linux", node="smok.home.front", ...}) = 0 3121 brk(0) = 0x806dd50 3121 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) 3121 open("/etc/ld.so.cache", O_RDONLY) = 3 3121 fstat64(3, {st_mode=S_IFREG|0644, st_size=111640, ...}) = 0 3121 old_mmap(NULL, 111640, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40013000 3121 close(3) = 0 3121 open("/lib/i686/libc.so.6", O_RDONLY) = 3 ...... 3121 open("/usr/share/locale/en_CA.UTF-8/LC_MESSAGES/tar.mo", O_RDONLY) = -1 ENOENT (No such file or directory) 3121 open("/usr/share/locale/en_CA.utf8/LC_MESSAGES/tar.mo", O_RDONLY) = -1 ENOENT (No such file or directory) 3121 open("/usr/share/locale/en_CA/LC_MESSAGES/tar.mo", O_RDONLY) = -1 ENOENT (No such file or directory) 3121 open("/usr/share/locale/en.UTF-8/LC_MESSAGES/tar.mo", O_RDONLY) = -1 ENOENT (No such file or directory) 3121 open("/usr/share/locale/en.utf8/LC_MESSAGES/tar.mo", O_RDONLY) = -1 ENOENT (No such file or directory) 3121 open("/usr/share/locale/en/LC_MESSAGES/tar.mo", O_RDONLY) = -1 ENOENT (No such file or directory) 3121 write(1, "tar (GNU tar) 1.13.25\nCopyright "..., 297) = 297 3068 <... select resumed> ) = 1 (in [11], left {0, 994077}) 3121 munmap(0x40013000, 4096 <unfinished ...> 3068 rt_sigaction(SIGCHLD, NULL, <unfinished ...> 3121 <... munmap resumed> ) = 0 3068 <... rt_sigaction resumed> {0x40055ca0, [CHLD], SA_RESTORER, 0x42028c48}, 8) = 0 3121 _exit(0) = ? 3068 rt_sigaction(SIGCHLD, {0x40055ca0, [CHLD], SA_RESTORER|SA_RESTART, 0x42028c48}, NULL, 8) = 0 3068 read(11, "tar (GNU tar) 1.13.25\nCopyright "..., 1024) = 297 3068 rt_sigaction(SIGCHLD, NULL, {0x40055ca0, [CHLD], SA_RESTORER|SA_RESTART, 0x42028c48}, 8) = 0 3068 rt_sigaction(SIGCHLD, {0x40055ca0, [CHLD], SA_RESTORER, 0x42028c48}, NULL, 8) = 0 3068 select(1024, [11 14], NULL, NULL, {1, 0}) = 2 (in [11 14], left {1, 0}) 3068 rt_sigaction(SIGCHLD, NULL, {0x40055ca0, [CHLD], SA_RESTORER, 0x42028c48}, 8) = 0 3068 rt_sigaction(SIGCHLD, {0x40055ca0, [CHLD], SA_RESTORER|SA_RESTART, 0x42028c48}, NULL, 8) = 0 3068 read(11, "", 1024) = 0 3068 read(14, "", 1024) = 0 3068 wait4(3121, <unfinished ...> ........ (and we are hanging here until the whole session is killed after logging overa network; sometimes things refuse to go away until reboot). I am not sure if this is really sawfish. The whole gnome-session setup seems to be currently so delicate that looking at it a wrong way is messing it up. The trace above suggests that locale stuff may be responsible.