Paul Leiber (HE12026-03-02):
> There are no open processes of the user after logout. (The line <logout
> wait="2000" hup="0" term="1" kill="1"/> should have taken care of that
> anyway, if I am not mistaken.)
You might think that. But I have a slew of computers where KDE, and
GNOME before that, leaves process lingering long after the user has
logged out, keeping the session nominally open. And filling up /var
because we log running process regularly.
It is on Ubuntu 22, it does not seem to happen on Trixie, but I have not
yet deployed it.
> I still think that the problem lies with pmvarrun not being called to
> decrease the entry for a user at logout.
I have slightly different diagnostic. See below.
> Here is an excerpt of my journal:
Two pieces of advice about it:
- Avoid localizing the dates in your journal, especially if it causes
non-ASCII characters to be present. If you got that from journalctl,
then it was localized only when printing, so you need to worry about
it only when sharing excerpts like that.
As a general principle, localizing system messages means you can get
confusing information from the message itself or from its
localization, not just from the message itself.
- Avoid line-rewrapping on log messages. I had to
`%s/> Mär.*\zs\n> \ze[^M]/` multiple times to read it properly.
> Mär 02 10:22:44 computer login[13770]: command: '/usr/sbin/pmvarrun' '-u'
> 'xxx'
> Mär 02 10:22:44 computer login[13770]: (pam_mount.c:441): pmvarrun says login
> count is 17
> Mär 02 10:22:47 computer login[13770]: command: '/usr/sbin/pmvarrun' '-u'
> 'xxx'
> Mär 02 10:22:47 computer login[13770]: (pam_mount.c:441): pmvarrun says login
> count is 18
What I am seeing is pam called from login calling pmvarrun twice the
same way with options `-u xxx`.
But in the source code, I see:
modify_pm_count(&Config, Config.user, "1");
in pam_sm_open_session() and
if (modify_pm_count(&Config, Config.user, "-1") > 0)
in pam_sm_close_session(), and it connects to:
{CMD_PMVARRUN, NULL, {"pmvarrun", "-u", "%(USER)", "-o",
"%(OPERATION)", NULL}},
So what we should be seeing is:
command: '/usr/sbin/pmvarrun' '-u' 'xxx' '-o' '1'
command: '/usr/sbin/pmvarrun' '-u' 'xxx' '-o' '-1'
If pam-mount forgets the -o option, then it defaults to 1, and it would
explain the mount count increasing each time.
But it needs to be confirmed, because it also could just be a bug /
misfeature of the code that logs the command. There is an easy way to do
it: just before you valid your password, from another terminal, run as
root:
strace -f -s 10000 -e execve -p $(pidof login | tr ' ' ,) -o /tmp/strace_login
Translation:
strace → dump the system calls done by processes;
-f → including subprocesses after a fork;
-s 10000 → with a very high limit to truncate strings and lists
-e execve → only the system call that starts a new process
-p … → trace these processes
$(pidof login …) → theses processes = the login process
| tr ' ' , → replace spaces with commas in case there are several
-o … save the output in that file
Then you look at the file to see how pmvarrun is invoked.
If you see it invoked with the -o option, then it is a false lead and
the issue is somewhere else.
If you see it invoked as shown in the logs, then we have surrounded the
issue, and somebody needs to debug the source code to see where the -o
option gets lost. (But we have reached the limit of the investigating
that I was willing to do.)
Regards,
--
Nicolas George
