Discussion:
Odd effect when using systemd-analyze verify in RPM %check
(too old to reply)
Ulrich Windl
2021-03-15 15:54:45 UTC
Permalink
Hi!

While constructing a new RPM package I tried "systemd-analyze verify" as %check, resulting in:
...
Failed to open /dev/tty0: Permission denied
...
ll /dev/tty /dev/tty0
crw-rw-rw- 1 root tty 5, 0 Mar 15 16:26 /dev/tty
crw--w---- 1 root tty 4, 0 Mar 11 10:11 /dev/tty0

What's the issue with running "systemd-analyze verify" and non-root?
When I run the same command with "su -c", then it does not print that message.

My TTY is "pts/1" (says "w").

(systemd-228 of SLES12 SP5)

Despite of that: Did anyone succeed using "systemd-analyze verify" in an RPM %chehck without having to install half of the system into buildroot?

Regards,
Ulrich Windl
Ulrich Windl
2021-03-17 06:52:22 UTC
Permalink
in
Hi!
While constructing a new RPM package I tried "systemd‑analyze verify" as
...
Failed to open /dev/tty0: Permission denied
...
ll /dev/tty /dev/tty0
crw‑rw‑rw‑ 1 root tty 5, 0 Mar 15 16:26 /dev/tty
crw‑‑w‑‑‑‑ 1 root tty 4, 0 Mar 11 10:11 /dev/tty0
What's the issue with running "systemd‑analyze verify" and non‑root?
This has been fixed a long time ago.
/dev/tty0 is the foreground console, so it changes identity whenever
you switch VT.
"systemd‑analyze verify" ultimately just runs the service manager with
different parameters, and there was a bug once upon a time, where the
service manager would use /dev/tty0 as it does when running PID1, but
of course it should not when running on a console.
Maybe update to something less ancient, or ask your distro to backport
the fix.
Maybe if you could either provide the version when it was fixed or maybe even
the commit that fixed it, I'd be happy to report this bug to my distribution.
Lennart
‑‑
Lennart Poettering, Berlin
Loading...