[Bug 739438] New: /tmp cleanup breaks keyring ...
https://bugzilla.novell.com/show_bug.cgi?id=739438 https://bugzilla.novell.com/show_bug.cgi?id=739438#c0 Summary: /tmp cleanup breaks keyring ... Classification: openSUSE Product: openSUSE 12.1 Version: Final Platform: Other OS/Version: Other Status: NEW Severity: Critical Priority: P5 - None Component: GNOME AssignedTo: bnc-team-gnome@forge.provo.novell.com ReportedBy: mmeeks@suse.com QAContact: qa@suse.de Found By: --- Blocker: --- This is really rather annoying. After being logged in for some days I inevitably loose my gnome-keyring / ssh authentication - which is particularly irritating when it comes to git pulling / re-authenticating etc. If I want to keep my session / IRC logs etc. etc. I have to run a manual ssh agent. The question is why; then again it seems that something newish (11.4/12.1) is cleaning up /tmp/ regularly that used not to happen (for me). Here is a (now) malfunctioning shell that used to work: $ echo $SSH_AUTH_SOCK /tmp/keyring-aZL9mi/ssh $ ls -l /tmp/keyring-aZL9mi/ssh ls: cannot access /tmp/keyring-aZL9mi/ssh: No such file or directory $ ls -al /tmp/keyring-aZL9mi/ total 68 drwx------ 2 michael users 4096 Dec 7 14:40 . drwxrwxrwt 93 root root 61440 Jan 4 09:05 .. Ok - so the socket is not there - odd; but the keyring process is still alive: $ ps ax | grep gnome-keyring 13853 ? SLl 0:13 /usr/bin/gnome-keyring-daemon --daemonize --login $ lsof -p 13853 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME .. gnome-key 13853 michael 0r CHR 1,3 0t0 1029 /dev/null gnome-key 13853 michael 1r CHR 1,3 0t0 1029 /dev/null gnome-key 13853 michael 2r CHR 1,3 0t0 1029 /dev/null gnome-key 13853 michael 3u 0000 0,9 0 3701 anon_inode gnome-key 13853 michael 4u unix 0xf1b14dc0 0t0 15682530 /tmp/keyring-aZL9mi/control gnome-key 13853 michael 5u unix 0xf2e96b80 0t0 15682960 /tmp/keyring-aZL9mi/pkcs11 gnome-key 13853 michael 6u unix 0xf7296b80 0t0 15683675 /tmp/keyring-aZL9mi/ssh gnome-key 13853 michael 7u 0000 0,9 0 3701 anon_inode gnome-key 13853 michael 8u unix 0xf3337dc0 0t0 15683728 socket gnome-key 13853 michael 9u unix 0xf1989dc0 0t0 15680685 socket gnome-key 13853 michael 10u 0000 0,9 0 3701 anon_inode gnome-key 13853 michael 11u 0000 0,9 0 3701 anon_inode gnome-key 13853 michael 12u unix 0xf2166280 0t0 15682609 /tmp/keyring-aZL9mi/pkcs11 gnome-key 13853 michael 14u unix 0xf2166040 0t0 15682608 /tmp/keyring-aZL9mi/gpg gnome-key 13853 michael 16u unix 0xf2d394c0 0t0 15698692 socket Oh - the keyring -thinks- that all those files are still there: indeed, it has them open [!] Almost certainly the culprit is a highly over-enthusiastic /tmp/ cleaner ... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=739438
https://bugzilla.novell.com/show_bug.cgi?id=739438#c1
--- Comment #1 from Michael Meeks
https://bugzilla.novell.com/show_bug.cgi?id=739438
https://bugzilla.novell.com/show_bug.cgi?id=739438#c2
--- Comment #2 from Michael Meeks
https://bugzilla.novell.com/show_bug.cgi?id=739438
https://bugzilla.novell.com/show_bug.cgi?id=739438#c3
Michael Meeks
https://bugzilla.novell.com/show_bug.cgi?id=739438
https://bugzilla.novell.com/show_bug.cgi?id=739438#c4
--- Comment #4 from Frederic Crozat
https://bugzilla.novell.com/show_bug.cgi?id=739438
https://bugzilla.novell.com/show_bug.cgi?id=739438#c5
--- Comment #5 from Michael Meeks
https://bugzilla.novell.com/show_bug.cgi?id=739438
https://bugzilla.novell.com/show_bug.cgi?id=739438#c6
Michal Svec
everything is controlled by tmpfiles.d (man tmpfiles.d). /usr/lib/tmpfiles.d/tmp.conf could be the guilty one:
Why the heck are _configuration_ files in /usr/lib?? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=739438
https://bugzilla.novell.com/show_bug.cgi?id=739438#c7
--- Comment #7 from Frederic Crozat
(In reply to comment #4)
everything is controlled by tmpfiles.d (man tmpfiles.d). /usr/lib/tmpfiles.d/tmp.conf could be the guilty one:
Why the heck are _configuration_ files in /usr/lib??
Because those are "default" configuration, which can be overridden by dropping a file with the same name in /etc/tmpfiles.d (just like systemd unit files or udev rules). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=739438
https://bugzilla.novell.com/show_bug.cgi?id=739438#c8
Morten Welinder
/tmp/orbit-*
The other side of that coin is that orbit likes to put thousands upon thousands of files into that directory -- this is the kind of thing that /tmp cleaning aims to fix. Not to blame the victim, but is there a reason why the keyring cannot be told to "touch" its file (say) daily? And similarly with pulse-audio. (I would pay to see the fight between the author of pulse-audio and the author of systemd over what to do here, ;-) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=739438
https://bugzilla.novell.com/show_bug.cgi?id=739438#c9
--- Comment #9 from Michael Meeks
The other side of that coin is that orbit likes to put thousands upon thousands of files into that directory -- this is the kind of thing that /tmp cleaning aims to fix.
ORBit2 loves it ;-) if you run 'linc-cleanup-sockets' at login in your session that should clean it up - but that never quite seems to happen on real systems I think. I am optimistic that systemd might not delete files that are really sockets - which would prolly rescue ORBit2 - not that I see any sockets there now we have gconf-dbus goodness around the place. Of course, if we were really having a bad day, we could grok all of /proc/*/fd to see if any of these files are open by some process: it happens the keyring ones are left open and not delete files that are open. It rather makes me wonder how LibreOffice will cope with having it's file data deleted from underneath it; we rather rely on having semi-persistent data in /tmp/ at least for the lifetime of our process [ not that that is typically left open though ... ] -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=739438
https://bugzilla.novell.com/show_bug.cgi?id=739438#c10
--- Comment #10 from Michael Meeks
https://bugzilla.novell.com/show_bug.cgi?id=739438
https://bugzilla.novell.com/show_bug.cgi?id=739438#c11
--- Comment #11 from Frederic Crozat
https://bugzilla.novell.com/show_bug.cgi?id=739438
https://bugzilla.novell.com/show_bug.cgi?id=739438#c12
--- Comment #12 from Bernhard Wiedemann
https://bugzilla.novell.com/show_bug.cgi?id=739438
https://bugzilla.novell.com/show_bug.cgi?id=739438#c13
Dominique Leuenberger
participants (1)
-
bugzilla_noreply@novell.com