GNOME Bugzilla – Bug 444957
gnome-screenshot does not save the file. Blocks indefinitely
Last modified: 2008-07-20 20:14:17 UTC
Please describe the problem: Running gnome-screenshot (or pressing PrtScr or ALT+PrtScr), I can see the small thumbnail image of the screen, as expected. But when I enter a filename, and click Save, the application waits forever, and never actually writes the file. I've tried my home directory, and /tmp. I've checked file permissions on the paths, and it still never writes the file. Running gnome-screenshot from a console prints no error messages. Steps to reproduce: 1. Run gnome-screenshot 2. Attempt to save the file 3. Actual results: The window "dims" by disabling all of the input fields, buttons, and shading the thumbnail image. Nothing further happens after this. I can click the "X" to close the window, but it never writes the file. Expected results: Should save the screenshot image. Does this happen every time? Yes. Other information: I ran the program through strace, and found that while it was doing nothing, the last thing seen in the strace output is: ioctl(3, FIONREAD, [32]) = 0 read(3, "s\0\200\7\1\0@\1\256W\340\2\1\0\0\0\303\243`\0\303\243"..., 32) = 32 ioctl(3, FIONREAD, [0]) = 0 poll( (it just stops at "poll(", but I dont it isn't frozen or crashed or anything, because moving my mouse over the window causes additional output, but it always comes back to the "poll(") Running through gdb to get a backtrace, I get: (gdb) bt
+ Trace 138931
This seems to confirm that it's getting to a poll() and then doesn't do anything after that. I'm running Gnome 2.18.0 and gnome-utils 2.18.1, on Gentoo Linux (from portage). Kernel is 2.6.20 (with reiser4 patches, but the directory I'm trying to save to is NOT a reiser4 partition), and Xorg 7.2.0. It might also be necessary information to know that I'm running compiz and gtk-window-decorator (XGL). I will try with metacity as well and see if I can get anything further.
I tried it without compiz or gtk-window-decorator, and I get the same behavior: $ ps aux | grep -e compiz -e metacity maejrep 11873 0.3 0.5 83388 11960 ? S 02:48 0:00 /usr/bin/metacity --sm-client-id=default0 If I can find a suitable replacement for gnome-screenshot, then I'll just use that. But this looks like a bug to me, even though I haven't been able to find anyone else reporting the same behavior.
Hey Joe, I think you've encountered a problem in another bug! Bug 427870 that is. Check the ownership and permissions of /tmp/gnome-screenshot and you will find it is probably 700 for a user other than yourself. You can either change it to be owned by your, or if that interferes with a multiuser system, you could change the persmissions to be 777, allowing everyone to use it (but perhaps exposing all your screenshots to the system?). At least, I suffered your symptoms and this turned out to be the problem.
I think Richard's right - it looks like the fix to bug 427870 will fix this issue. Joe_H - can you tell us whether other people use your system? Could someone with a different user account have used the screenshot utility before you? I'm changing the status of this bug to duplicate. If it turns out that this bug isn't caused by another user using the screenshot utility, I'll reopen it. *** This bug has been marked as a duplicate of 427870 ***
Richard, sorry, I somehow missed your response from a year ago... This was not a multi-user system. I was the only user on the system, however that system has since been reinstalled, so I cannot verify the /tmp/gnome-screenshot permissions. I'm now running 2.20.3, and have not noticed the problem I described above since I stopped using the system I was using at the time of the bug. 427870 may very well be the same problem as what I was having, even though it was not a multi-user system. But since I cannot confirm either way, I'll leave this as closed. If the /tmp file persisted across reboots, then that seems like a reasonable cause, because I had logged in on that machine as root, and the problem persisted across reboots, so it's possible that the file was in /tmp writable only to root, and that caused the problem.