#75250 ssh: syslogin_perform_logout: logout() returned an error

Package:
ssh
Source:
openssh
Submitter:
Kresimir Kukulj
Date:
2025-07-14 07:29:01 UTC
Severity:
wishlist
Tags:
#75250#5
Date:
2000-10-20 19:00:32 UTC
From:
To:
This is in auth.log:
sshd[15660]: Accepted password for madmax from xxxx
PAM_unix[15660]: (ssh) session opened for user madmax by (uid=0)
sshd[15660]: syslogin_perform_logout: logout() returned an error
PAM_unix[15660]: (ssh) session closed for user madmax
[ this was interactive shell ]

sshd[15821]: Accepted password for madmax from xxxx
PAM_unix[15821]: (ssh) session closed for user madmax
sshd[15821]: PAM pam_putenv: delete non-existent entry; MAIL
[ this was I think scp ]

Also it seems that it doesn't update /var/run/utmp when user logs out.
#75250#10
Date:
2025-06-03 12:37:16 UTC
From:
To:
Closing this ticket because it is out-dated and there was no activity.
No
activity means also no interest from maintainer nor the reporter. The
package
might be not actively maintained anymore.

This happens in interest of Debian GNU/Linux project because it harms
the
project keeping tickets of that age open without any activity, decision
or
action taken.

Feel free to re-open or open a fresh report.
#75250#17
Date:
2025-06-17 23:34:09 UTC
From:
To:
Dear Maintainer,

this message is the result of a missing (/var)/run/utmp. OpenSSH tries
to write, but this file does not exists in a default installation. To
resolve this issue we can create /run/utmp.
#75250#24
Date:
2025-07-12 13:26:57 UTC
From:
To:
It seems that on a fresh trixie install, nothing creates /run/utmp
anymore.  Is that a bug or is utmp deprecated? who and who -b still seem
to work, so not sure how who finds its information, and if this means
utmp is not required anymore.

According to Googel Gemini (sorry...):

    Yes, it is by design that /run/utmp is no longer provided in Debian
    Trixie.

    This change is primarily due to:

    Year 2038 Problem (Y2K38): The traditional utmp file format uses 32-bit
    timestamps, which are susceptible to the Year 2038 problem. After
    January 19, 2038, these timestamps will overflow, leading to incorrect
    date and time readings. Upstream developers for the utmp format have
    been unwilling to change it.
    

    Modern systemd Session Management: systemd (which Debian uses as its
    init system) has its own, more robust, and modern session management
    capabilities. Information about active sessions, login times, and other
    user accounting data is now primarily managed by systemd itself, often
    exposed via logind and its API.

So maybe sshd should ignore any error connected to utmp, instead of
throwing an error.


Thanks,
Paul
#75250#29
Date:
2025-07-12 13:57:49 UTC
From:
To:
utmp is deprecated, indeed.

Chris
#75250#34
Date:
2025-07-12 14:17:15 UTC
From:
To:
The following message is a courtesy copy of an article
that has been posted to gmane.linux.debian.devel.ssh as well.

Paul Slootman <paul@debian.org> writes:

The draft release-notes for trixie do have some information on this,
https://www.debian.org/releases/trixie/release-notes/issues.en.html#things-to-be-aware-of-while-upgrading-to-releasename

but it we dont mention who(1) at all - should we say it continues to work?
(im not sure if it matters enough?)

https://manpages.debian.org/testing/coreutils/who.1.en.html stills refer
to /var/run/utmp - not sure if that is just a documentation bug of if
who is broken too ('who' doesnt return anything in a chroot for me)?
#75250#39
Date:
2025-07-12 21:45:50 UTC
From:
To:
It seems wrong to me to list all things that just continue to work.

In a chroot, who should (most of the time) not show anything,
because there was never a login.

Chris
#75250#44
Date:
2025-07-14 07:27:50 UTC
From:
To:
I agree.
I mentioned that who(1) still worked, to indicate that apparently utmp
is deprecated (I did miss the documentation on that). So sshd should not
report an error if it fails to update utmp .


Paul