[systemd-devel] Antw: [EXT] Re: [systemd‑devel] systemctl log verbosity

[Michael Chapman]

On Wed, 18 Aug 2021, Ulrich Windl wrote:
> >>> Michael Chapman <mike at very.puzzling.org> schrieb am 18.08.2021 um 08:38 in
> Nachricht <f3d742a-53ca-85c7-32eb-adf8e682c3d1 at very.puzzling.org>:
> > On Wed, 18 Aug 2021, Ulrich Windl wrote:
> >> >>> Michael Chapman <mike at very.puzzling.org> schrieb am 17.08.2021 um 02:52
> in
> >> Nachricht <885331af-bb7-41d0-e8-26c92023bb77 at very.puzzling.org>:
> >> > On Tue, 17 Aug 2021, Dave Close wrote:
> >> >> I'm trying to run "systemctl show" in a cron script. It works but I get
> >> >> a huge number of extra lines in my log for each run. Why? Can this be
> >> >> suppressed. I don't want to overfill the log.
> >> >> 
> >> >> There is nothing in the man page (that I noticed) indicating that
> "show"
> >> >> causes anything to be logged. But here's an example of what I see.
> >> >> 
> >> >> >Aug 16 16:10:01 svcs systemd[1]: Created slice User Slice of UID 0.
> >> >> >Aug 16 16:10:01 svcs systemd[1]: Starting User Runtime Directory 
> >> > /run/user/0...
> >> >> >Aug 16 16:10:01 svcs systemd[1]: Finished User Runtime Directory 
> >> > /run/user/0.
> >> >> >Aug 16 16:10:01 svcs systemd[1]: Starting User Manager for UID 0...
> >> >> >Aug 16 16:10:01 svcs systemd[80491]: Queued start job for default
> target 
> >> > Main User Target.
> >> >> >Aug 16 16:10:01 svcs systemd[80491]: Created slice User Application
> >> Slice.
> >> >> >Aug 16 16:10:01 svcs systemd[80491]: Condition check resulted in Mark
> boot
> >> 
> >> > as successful after the 
> >> >> user session has run 2 minutes being skipped.
> >> >> >Aug 16 16:10:01 svcs systemd[80491]: Started Daily Cleanup of User's 
> >> > Temporary Directories.
> >> >> >Aug 16 16:10:01 svcs systemd[80491]: Reached target Paths.
> >> >> >Aug 16 16:10:01 svcs systemd[80491]: Reached target Timers.
> >> >> >Aug 16 16:10:01 svcs systemd[80491]: Starting D‑Bus User Message Bus
> >> Socket.
> >> >> >Aug 16 16:10:01 svcs systemd[80491]: Condition check resulted in
> PipeWire
> >> 
> >> > PulseAudio being skipped.
> >> >> >Aug 16 16:10:01 svcs systemd[80491]: Listening on Multimedia System.
> >> >> >Aug 16 16:10:01 svcs systemd[80491]: Starting Create User's Volatile
> Files
> >> 
> >> > and Directories...
> >> >> >Aug 16 16:10:01 svcs systemd[80491]: Finished Create User's Volatile
> Files
> >> 
> >> > and Directories.
> >> >> >Aug 16 16:10:01 svcs systemd[80491]: Listening on D‑Bus User Message
> Bus 
> >> > Socket.
> >> >> >Aug 16 16:10:01 svcs systemd[80491]: Reached target Sockets.
> >> >> >Aug 16 16:10:01 svcs systemd[80491]: Reached target Basic System.
> >> >> >Aug 16 16:10:01 svcs systemd[80491]: Reached target Main User Target.
> >> >> >Aug 16 16:10:01 svcs systemd[80491]: Startup finished in 151ms.
> >> >> >Aug 16 16:10:01 svcs systemd[1]: Started User Manager for UID 0.
> >> >> >Aug 16 16:10:01 svcs systemd[1]: Started Session 72 of User root.
> >> >> >Aug 16 16:10:01 svcs root[80504]: ## logger output from cron script ##
> >> >> >Aug 16 16:10:01 svcs systemd[1]: session‑72.scope: Deactivated
> >> successfully.
> >> >> 
> >> >> I see these additional 23 lines (plus the one‑line script output) every
> >> >> time the script runs. That seems excessively verbose to me.
> >> >> 
> >> >> The system is Fedora 34 x86_64.
> >> > 
> >> > Cron jobs are run with pam_systemd, so they are run within a logind 
> >> > session. If there is no other sessions for root at that time, root's own
> 
> >> > systemd manager is started when the Cron job launches, and is stopped
> when 
> >> > the Cron job terminates. All of these log messages are related to this.
> >> > 
> >> > You may instead want to make root a lingering user:
> >> > 
> >> >     loginctl enable‑linger root
> >> > 
> >> > This setting is persistent. You can use disable‑linger at a later time to
> 
> >> > turn it off if necessary.
> >> > 
> >> > With root configured as a lingering user, its systemd manager remains 
> >> > running all the time.
> >> 
> >> After reading the manual page I wonder: Is tha tsetting persistent, i.e.:
> >> Where is that setting stored?
> > 
> > Yes, it is persistent.
> > 
> > Lingering users are just represented as files under 
> > /var/lib/systemd/linger/ (though this is an implementation detail, of 
> > course).
> 
> Of course, but the manual page of systemd-logind.service could state that
> settings are saved persistently "somewhere".
> Currently it does not even mention "linger", but the binary has the string
> "Failed to open /var/lib/systemd/linger/: %m" inside.

Well, the loginctl documentation says:

    If enabled for a specific user, a user manager is spawned for
    the user at boot and kept around after logouts.

Which kind of implies that there must be some persistent state somewhere 
-- how else would it do this "at boot"? The actual nature of this state 
isn't really that important.