Your message dated Mon, 02 Dec 2024 22:23:34 +0100
with message-id <87o71taieh....@err.no>
and subject line Re: Bug#760022: libpam-tmpdir fails to work properly with
systemd and suspend
has caused the Debian Bug report #760022,
regarding libpam-tmpdir fails to work properly with systemd and suspend
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
760022: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760022
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libpam-tmpdir
Version: 0.09
Severity: important
Dear Maintainer,
I recently switch my Debian/testing system to use systemd for init
functionality. Prior to this I had been using libpam-tmpdir for awhile
without any problems. After switching to systemd I began having issues when
resuming the system from suspend or hibernate.
The problem manifested itself by files in the tmpdir going missing after
resuming. In my case, I am using byobu and an emacs daemon, each of which
creates a socket in its respective tmp directory. Upon resuming from
suspend/hibernate these tmp files are no longer present. The processes aren't
killed, but their utilities can no longer communicate with them.
Given the complexity of systemd, I'm not sure where the conflict arises.
Considering how frequently systemd seems to create and tear down sessions,
that seems a likely area for problems. I think the only PAM module that
touches tmp-anything is libpam-tmpdir, so my best guess is that at some point,
pre-suspend, systemd removes the user session triggering libpam-tmpdir to
remove the user tmpdir and anything in it. When the system resumes, systemd
creates a new session and libpam-tmpdir creates a new per-user tmpdir, but it
is, of course, now empty.
This is just a guess though. Whatever systemd is doing isn't *completely*
removing the user session since existing user processes are not killed.
Perhaps it has something to do with the addition of cgroups that systemd
provices? I'm not sure.
If I can provide any additional information, please let me know.
--
--John Gruenenfelder Systems Manager, MKS Imaging Technology, LLC.
Try Weasel Reader for PalmOS -- http://weaselreader.org
"This is the most fun I've had without being drenched in the blood
of my enemies!"
--Sam of Sam & Max
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libpam-tmpdir depends on:
ii libc6 2.19-9
ii libpam-runtime 1.1.8-3.1
ii libpam0g 1.1.8-3.1
ii multiarch-support 2.19-9
libpam-tmpdir recommends no packages.
libpam-tmpdir suggests no packages.
-- no debconf information
signature.asc
Description: Digital signature
--- End Message ---
--- Begin Message ---
]] Tollef Fog Heen
> libpam-tmpdir never cleans up the temporary directory, though, so I'm
> not sure how this would happen. If anything it sounds like a systemd
> bug. Are you still experiencing this, or did it get resolved in the
> meantime?
I never received a response, so I assume this is no longer a problem.
Feel free to reopen if this is not the case.
Regards,
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
--- End Message ---
