Bug 1224148

Summary: sddm-helper should not write utmp entry if utmp file does not exist
Product: [openSUSE] openSUSE Tumbleweed Reporter: Marcus Rückert <mrueckert>
Component: KDE Workspace (Plasma)Assignee: E-Mail List <opensuse-kde-bugs>
Status: NEW --- QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None CC: fkrueger, fvogt, krinpaus, kukuk
Version: CurrentFlags: fvogt: needinfo?
Target Milestone: ---   
Hardware: Other   
OS: Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Marcus Rückert 2024-05-12 01:07:59 UTC
sddm-helper[1263]: Failed to write utmpx:  No such file or directory
Comment 1 Frank Krüger 2024-05-12 08:19:25 UTC
JFYI: I am seeing this error message also with the former version lastlog2-1.3.1-1.1.x86_64.
Comment 2 Thorsten Kukuk 2024-05-12 08:53:50 UTC
utmp has absolute nothing to do with lastlog/lastlog2.
Comment 3 Fabian Vogt 2024-05-13 11:04:28 UTC
What should sddm do? Just ignore ENOENT?
Comment 4 Thorsten Kukuk 2024-05-13 11:41:05 UTC
(In reply to Fabian Vogt from comment #3)
> What should sddm do? Just ignore ENOENT?

glibc (and several other implementations I saw) do a "return 0" if the utmp file cannot be open'd, for all reasons.
So they do nothing if they cannot open the utmp file RDONLY.
Comment 5 Fabian Vogt 2024-05-13 11:59:49 UTC
(In reply to Thorsten Kukuk from comment #4)
> (In reply to Fabian Vogt from comment #3)
> > What should sddm do? Just ignore ENOENT?
> 
> glibc (and several other implementations I saw) do a "return 0" if the utmp
> file cannot be open'd, for all reasons.
> So they do nothing if they cannot open the utmp file RDONLY.

This is about writing, i.e. pututxline. That appears to fail. SDDM does

        // fill entry ...

        // write to utmp
        setutxent();
        if (!pututxline (&entry))
            qWarning() << "Failed to write utmpx: " << strerror(errno);
        endutxent();

Should SDDM explicitly ignore ENOENT?

Some compile time detection would be fine as well, but I don't see anything fitting.