After upgrade to ucs 4.3-4 /var/log/journal grows up

[bbassotti]

Hi, the directory /var/log/journal/xxx grows rapidly up to fill the entire fs, lots of files like:

user-XYZK.journal

– Logs begin at Wed 2019-06-19 21:26:15 CEST, end at Wed 2019-06-19 22:26:36 CEST. –
Jun 19 21:26:15 ucsdc systemd[29943]: Listening on GnuPG network certificate management daemon.
Jun 19 21:26:15 ucsdc systemd[29943]: Listening on GnuPG cryptographic agent (access for web browsers).
Jun 19 21:26:15 ucsdc systemd[29943]: Listening on GnuPG cryptographic agent (ssh-agent emulation).
Jun 19 21:26:15 ucsdc systemd[29943]: Reached target Timers.
Jun 19 21:26:15 ucsdc systemd[29943]: Listening on GnuPG cryptographic agent and passphrase cache (restricted).
Jun 19 21:26:15 ucsdc systemd[29943]: Listening on GnuPG cryptographic agent and passphrase cache.
Jun 19 21:26:15 ucsdc systemd[29943]: Reached target Sockets.
Jun 19 21:26:15 ucsdc systemd[29943]: Reached target Paths.
Jun 19 21:26:15 ucsdc systemd[29943]: Reached target Basic System.
Jun 19 21:26:15 ucsdc systemd[29943]: Reached target Default.
Jun 19 21:26:15 ucsdc systemd[29943]: Startup finished in 17ms.
Jun 19 21:26:31 ucsdc systemd[29943]: Stopped target Default.
Jun 19 21:26:31 ucsdc systemd[29943]: Stopped target Basic System.
Jun 19 21:26:31 ucsdc systemd[29943]: Stopped target Timers.
Jun 19 21:26:31 ucsdc systemd[29943]: Stopped target Sockets.
Jun 19 21:26:31 ucsdc systemd[29943]: Closed GnuPG cryptographic agent (ssh-agent emulation).
Jun 19 21:26:31 ucsdc systemd[29943]: Closed GnuPG cryptographic agent and passphrase cache (restricted).
Jun 19 21:26:31 ucsdc systemd[29943]: Closed GnuPG cryptographic agent (access for web browsers).
Jun 19 21:26:31 ucsdc systemd[29943]: Closed GnuPG cryptographic agent and passphrase cache.
Jun 19 21:26:31 ucsdc systemd[29943]: Stopped target Paths.
Jun 19 21:26:31 ucsdc systemd[29943]: Closed GnuPG network certificate management daemon.
Jun 19 21:26:31 ucsdc systemd[29943]: Reached target Shutdown.
Jun 19 21:26:31 ucsdc systemd[29943]: Starting Exit the Session…
Jun 19 21:26:31 ucsdc systemd[29943]: Received SIGRTMIN+24 from PID 30040 (kill).

how to stop the growth or stop all this logs?

UPDATE: ucr set systemd/journald/Storage=none; systemctl restart systemd-journald

[Moritz_Bunkus]

A better method is to filter such messages as they’re practically irrelevant for daily operations. See the following article:

Problem: journalctl Reports Errors: "Failed to open directory /dev/null/.config/systemd"

Apr 15 10:58:37 ucs systemd[27863]: Failed to open directory /dev/null/.config/systemd/user/run-user-2327.mount.wants: Not a directory Apr 15 10:58:37 ucs systemd[27863]: Failed to open directory /dev/null/.config/systemd/user/run-user-2327.mount.requires: Not a directory Apr 15 10:58:37 ucs systemd[27863]: Failed to open directory /dev/null/.local/share/systemd/user/run-user-2327.mount.wants: Not a directory Apr 15 10:58:37 ucs systemd[27863]: Failed to open directory /dev/null/.local/share/…

[bbassotti]

Hi, are you sure it’s the best solution? why all those log files when there was no problem up until the previous release? with many computers and many users the load goes up a lot and you have lots of useless logs. Mine wants to be a constructive and not offensive criticism, it seems to me that you have made some mistakes. I don’t seem to be the only one to report these problems. Greetings.

[Moritz_Bunkus]

In all likelihood this wasn’t a a deliberate change on the part of the Univention team. Instead, it was likely a change introduced by newer versions of systemd or logind itself.

Sure, you’re not the only one reporting this as those messages occur for everyone runing a recent version of UCS. However, most people simply ignore those messages, as do I. The impact those messages have is negligible; they only occur each time a user opens a new connection that actually opens a system session, and that simply doesn’t happen all that often that it could induce high system load.

If the log file growth is something you’re worrying about, there are settings that control the maximum size of the journal; see man journald.conf (on UCS systems the journald.conf file is managed by UCR templates; see ucr search journal for the corresponding variables you can change). You don’t even have to worry about the journal filling up your file system as the journal daemon dosen’t just have a maximum journal size setting, it also has a setting for how much space it will leave at least on the file system (setting SystemKeepFree).

Additionally you can filter those messages as I’ve pointed out already.

This really isn’t a bug. It’s normal system behavior. That behavior has changed recently, sure, but software behavior changes all the time.

[bbassotti]

finally shut up you have solved the problem, good.

https://forge.univention.org/bugzilla/show_bug.cgi?id=49910