[SOLVED] SDDM noise in alt+F1 terminal since last update?

chrisretusn · 08-07-2023, 04:43 AM

If it wasn't happening before and it's now happening, it would be nice to know why and what.

lonestar_italy · 08-07-2023, 08:01 AM

the dev of sddm seems willing to do some changes to restore the expected behaviour when not using journald, so if anyone wants to contribute to the open issue on github with better/quicker feedback than the one I can provide, feel free

https://github.com/sddm/sddm/issues/1780

marav · 08-07-2023, 08:30 AM

Quote:

Originally Posted by lonestar_italy

the dev of sddm seems willing to do some changes to restore the expected behaviour when not using journald, so if anyone wants to contribute to the open issue on github with better/quicker feedback than the one I can provide, feel free

https://github.com/sddm/sddm/issues/1780

Until systemd is found, enable_journald (on or off) does nothing

Code:

if(SYSTEMD_FOUND)
    add_definitions(-DHAVE_SYSTEMD)
    set(CMAKE_AUTOMOC_MOC_OPTIONS -DHAVE_SYSTEMD)

    # libsystemd-journal was merged into libsystemd in 209
    if(${SYSTEMD_VERSION} VERSION_LESS 209)
        pkg_check_modules(JOURNALD "libsystemd-journal")
    else()
        pkg_check_modules(JOURNALD "libsystemd")
    endif()

    if(ENABLE_JOURNALD)
        if(JOURNALD_FOUND)
            add_definitions(-DHAVE_JOURNALD)
            set(CMAKE_AUTOMOC_MOC_OPTIONS -DHAVE_JOURNALD)
        else()
            message(WARNING "Disable journald support for lack of libsystemd-journal")
        endif()
    endif()

I only have very few lines (~15) in TTY1, mainly DAEMON and HELPER

And session logs (wayland & xorg) are in : .local/share/sddm/

lonestar_italy · 08-07-2023, 08:45 AM

Quote:

Originally Posted by marav

Until systemd is found, enable_journald (on or off) does nothing

but it should not find systemd in our case. OR would it need explicit -DHAVE_SYSTEMD=OFF ?

Quote:

Originally Posted by marav

I only have very few lines (~15) in TTY1, mainly DAEMON and HELPER

yes, it's not a tragedy, but it wasn't happening before 0.20 and also the output covers the login prompt on tty1 and any other thing should be there while a sddm event happens. More lines will add in case you log in more than once.

ZhaoLin1457 · 08-07-2023, 09:00 AM

Quote:

Originally Posted by lonestar_italy

yes, it's not a tragedy, but it wasn't happening before 0.20 and also the output covers the login prompt on tty1 and any other thing should be there while a sddm event happens. More lines will add in case you log in more than once.

Excuse me, but LuckyCyborg already said that we can simulate the behavior of systemd in this case with the supervisor daemon.

Indeed, the supervisor daemon included in Slackware can capture the output of the supervised program, sending it to syslog or to a log file.

Code:

-l spec, --errlog=spec
Send daemon's standard output and standard error to the syslog destination or file that is specified by spec. If spec is a syslog destination of the form "facility.priority",
then output is sent to syslog(3). Otherwise, output is appended to the file whose path is given in spec. By default, output is sent to the syslog destination, daemon.err. See
the MESSAGING section below for more details.

-b spec, --dbglog=spec
Send daemon's debug output to the syslog destination or file that is specified by spec. If spec is a syslog destination of the form "facility.priority", then output is sent
to syslog(3). Otherwise, output is appended to the file whose path is given in spec. By default, output is sent to the syslog destination daemon.debug. See the MESSAGING
section below for more details.

-o spec, --output=spec
Capture the client's standard output and standard error, and send it to the syslog destination or file that is specified by spec. If spec is a syslog destination of the form
"facility.priority", then output is sent to syslog(3). Otherwise, output is appended to the file whose path is given in spec. By default, output is discarded unless the
--foreground option is present, in which case, the client's stdout and stderr are propagated to daemon's stdout and stderr, respectively. See the MESSAGING section below for
more details.

-O spec, --stdout=spec
Capture the client's standard output, and send it to the syslog destination or file that is specified by spec. If spec is a syslog destination of the form
"facility.priority", then output is sent to syslog(3). Otherwise, stdout is appended to the file whose path is given in spec. By default, stdout is discarded unless the
--foreground option is present, in which case, the client's stdout is propagated to daemon's stdout. See the MESSAGING section below for more details.

-E spec, --stderr=spec
Capture the client's standard error, and send it to the syslog destination or file that is specified by spec. If spec is a syslog destination of the form "facility.priority",
then stderr is sent to syslog(3). Otherwise, stderr is appended to the file whose path is given in spec. By default, stderr is discarded unless the --foreground option is
present, in which case, the client's stderr is propagated to daemon's stderr. See the MESSAGING section below for more details.

This is from the man file for the daemon.

After all, I think there is no problem with SDDM. The problem is with the laziness of Slackware users to adapt to the evolution of programs, and the fact that they do not accept that something can change in their behavior. Amazing, but it happens.

My opinion is that those who are unhappy with the current behavior of SDDM, instead of pestering the SDDM developers, would do well to adapt the Slackware scripts.

If this additional work does not suit you gentlemen, stop insisting Slackware to swim against the river. The simplest way would be to use systemd like everyone else, right?

Quote:

Originally Posted by Vogtinator

It's been so long that I've used sysvinit that I have no idea what the expected behaviour is.

https://github.com/sddm/sddm/issues/...ent-1667255778

marav · 08-07-2023, 09:10 AM

Quote:

Originally Posted by lonestar_italy

but it should not find systemd in our case. OR would it need explicit -DHAVE_SYSTEMD=OFF ?

We already have it

Code:

option(NO_SYSTEMD "Disable systemd support" OFF)

Code:

mkdir -p cmake-build
cd cmake-build
  cmake \
    -DCMAKE_BUILD_TYPE=Release \
    -DCMAKE_C_FLAGS:STRING="$SLKCFLAGS" \
    -DCMAKE_C_FLAGS_RELEASE:STRING="$SLKCFLAGS" \
    -DCMAKE_CXX_FLAGS:STRING="$SLKCFLAGS" \
    -DCMAKE_CXX_FLAGS_RELEASE:STRING="$SLKCFLAGS" \
    -DCMAKE_INSTALL_PREFIX=/usr \
    -DCMAKE_INSTALL_MANDIR=/usr/man \
    -DLIB_SUFFIX=${LIBDIRSUFFIX} \
    -DBUILD_MAN_PAGES:BOOL=TRUE \
    -DDBUS_CONFIG_FILENAME="org.freedesktop.sddm.conf" \
    -DUSE_QT5:BOOL=TRUE \
    -DENABLE_JOURNALD:BOOL=FALSE \
    -DENABLE_PAM:BOOL=ON \
    -DNO_SYSTEMD:BOOL=TRUE \
    -DUSE_ELOGIND:BOOL=TRUE \
    ..

0XBF · 08-07-2023, 03:35 PM

From todays ChangeLog.txt:

Quote:

kde/sddm-0.20.0-x86_64-2.txz: Rebuilt.
Eliminate duplicate log messages polluting the first virtual console.

With the revised wrapper script '/usr/bin/sddm':

Code:

#!/bin/sh
# Customized environment (LANG definition):
if [ -f /etc/default/sddm ]; then
  . /etc/default/sddm
fi

# Ensure non-world readable permissions on /var/log/sddm.log:
touch /var/log/sddm.log
chmod 640 /var/log/sddm.log

# Add a timestamp:
date >> /var/log/sddm.log

# Redirect stdout/stderr to /dev/null to avoid polluting a virtual
# console with duplicate log messages:
exec /usr/bin/sddm.bin "$@" 1> /dev/null 2> /dev/null

pchristy · 08-08-2023, 03:09 AM

Yes, the latest update seems to have completely cleared the problem - without any need to invoke systemd or its work arounds (thank heavens!).

Many thanks to our Benevolent Dictator!

--
Pete

Jan K. · 08-08-2023, 05:41 PM

Quote:

Originally Posted by ZhaoLin1457

...The simplest way would be to use systemd like everyone else, right?

Hmmm... instead of adding two million lines of code, I by far prefer the one-liner offered.