https://bugs.kde.org/show_bug.cgi?id=444084
--- Comment #2 from pa...@web.de --- Some more observations: qCDebug really goes to stderr according to https://stackoverflow.com/a/26325743 "If the process' stderr has a console attached, that's where the debug log will go." So one idea could be, to remove stdout (due to the entry in the journal) and stderr (due to the quote above) from kscreen via systemd. Unfortunetly, there is no kscreen service unit. This is the shortened "systemd --user show" hierarchy: CGroup: /user.slice/user-1000.slice/user@1000.service ├─app.slice │ ├─dbus.service │ │ └─1273 /usr/lib/x86_64-linux-gnu/libexec/kf5/kscreen_backend_launcher So kscreen_backend-launcher is executed by dbus.service. However, changing stdout and stderr of dbus.service via "systemctl --user edit dbus.service" and adding [Service] StandardOutput=null StandardError=null although changing (after a restart) the configuration for dbus.service shown by "systemctl --user show dbus.service" to StandardOutput=null StandardError=null does not change the logging behavior. I assume this is, as kscreen_backend_launcher is probably started via dbus and therefore probably does not inherent stdout and stderr settings. This is confirmed by "ls -l /proc/$(pgrep kscreen)/fd" lrwx------ 1 pat pat 64 21. Okt 07:26 0 -> /dev/null lrwx------ 1 pat pat 64 21. Okt 07:26 1 -> 'socket:[17265]' lrwx------ 1 pat pat 64 21. Okt 07:26 2 -> 'socket:[17266]' So stdout and stderr do not go to /dev/null. This is what "lsof | rg 1726[56]" (rg is grep-like ripgrep) outputs: kscreen_b 1273 pat 1u unix 0x00000000a3854333 0t0 17265 type=STREAM kscreen_b 1273 pat 2u unix 0x00000000e0deba49 0t0 17266 type=STREAM kscreen_b 1273 1278 QXcbEvent pat 1u unix 0x00000000a3854333 0t0 17265 type=STREAM kscreen_b 1273 1278 QXcbEvent pat 2u unix 0x00000000e0deba49 0t0 17266 type=STREAM kscreen_b 1273 1280 QDBusConn pat 1u unix 0x00000000a3854333 0t0 17265 type=STREAM kscreen_b 1273 1280 QDBusConn pat 2u unix 0x00000000e0deba49 0t0 17266 type=STREAM 1273 is kscreen_backend_launcher (from "pgrep kscreen"). This is, what "ss | rg 1726[56]" outputs: u_str ESTAB 0 0 /run/systemd/journal/stdout 18202 * 17265 u_str ESTAB 0 0 * 17265 * 18202 u_str ESTAB 0 0 /run/systemd/journal/stdout 18203 * 17266 u_str ESTAB 0 0 * 17266 * 18203 According to "man systemd-journald" /run/systemd/journal/stdout is a "Socket[...] that systemd-journald will listen on and [is] visible in the file system". The question is, how to avoid this socket connection with systemd's stdout logging to the Journal and instead use the advanced normal logging mechanism? Or, maybe as a temporary workaround, at least reduce the priority of systemd's stdout logging. -- You are receiving this mail because: You are watching all bug changes.
