Version 2.1.1 clutters up the syslog

[temirg]

Hello Tuxedo-team,

the TCC / tccd v2.1.1 writes thousands of lines into the syslog in conjunction with two errors:

Dec 19 21:05:58 work17 systemd-journald[638]: Suppressed 123835 messages from tccd.service
Dec 19 21:05:58 work17 tccd[13063]: Authorization required, but no authorization protocol specified
Dec 19 21:06:01 work17 tccd[3323]: Last message 'Authorization requir' repeated 16131 times, suppressed by syslog-ng on work17
Dec 19 21:05:58 work17 tccd[13063]: Failed executing onWork() => Error: spawnSync /bin/sh ENOBUFS
Dec 19 21:06:01 work17 tccd[13063]: Authorization required, but no authorization protocol specified
Dec 19 21:06:03 work17 tccd[3323]: Last message 'Authorization requir' repeated 16132 times, suppressed by syslog-ng on work17

May be helpful regarding to "Failed executing onWork() => Error: spawnSync /bin/sh ENOBUFS": https://stackoverflow.com/questions/63796633/spawnsync-bin-sh-enobufs

If more details are needed - please let me know.

ENV:

System:
  Host: work17 Kernel: 6.6.6-1-default arch: x86_64 bits: 64
    Desktop: KDE Plasma v: 5.27.10 Distro: openSUSE Tumbleweed 20231218
Machine:
  Type: Laptop System: SchenkerGmbH product: SCHENKER WORK (Early 2021) v: N/A  serial: N/A
  Mobo: NB01 model: NS50_70MU serial: N/A UEFI: INSYDE v: 1.07.16NRTR4   date: 05/26/2022

Regards, temirg

EDIT: tccd CPU load ~ 1%

[kron4eg]

@temirg I've poked around the source, seems like your system is missing xrandr binary

[temirg]

@kron4eg that would be an easy solution. Unfortunately the xrandr was already installed:

work17:~ # zypper se -in xrandr
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...

S | Name       | Summary                                                    | Type
--+------------+------------------------------------------------------------+------
i | libXrandr2 | X Resize, Rotate and Reflection extension library          | Paket
i | xrandr     | Primitive Befehlszeilenschnittstelle zur RandR-Erweiterung | Paket

Regards, temirg

[munix9]

maybe that will help: xhost +si:localuser:root see https://github.com/tuxedocomputers/tuxedo-control-center/issues/336#issuecomment-1862397876

[temirg]

@munix9 : in fact, this temporary workaround makes tccd start and run without errors.

A permanent solution would be nicer. Do I now have to put it in /etc/X0.hosts or is Tuxedo already developing a fix?

@tuxedoxt : could you say something about that?

Regards, temirg.

[munix9]

@munix9 : in fact, this temporary workaround makes tccd start and run without errors.

A permanent solution would be nicer. Do I now have to put it in /etc/X0.hosts or is Tuxedo already developing a fix?

@tuxedoxt : could you say something about that?

Regards, temirg.

temporary, yes ...

possibly copy the following into /etc/bash.bashrc.local:

# required by tccd (tuxedo-control-center)
if test "$UID" -ne 0 -a -n "$DISPLAY" ; then
  xhost | grep -iqw "si:localuser:root" || xhost +si:localuser:root
fi

... or is Tuxedo already developing a fix?

I don't know

[right-0903]

just update your XAUTHORITY environment variable, do it in bash profile my sddm use random one in tmp, so tccd use ~/.Xauthority never work, refer this

[temirg]

@all: short conclusion: Tuxedo has nothing to do with the problem, the sddm DEVs do strange things...

The workaround with: readonly XAUTHORITY=$HOME/.Xauthority or export XAUTHORITY=$HOME/.Xauthority in /etc/bash.bashrc.local sends the sddm-helper into a crash loop.

The workaround from munix9 works.

I'm closing the issue as solved with workaround. Many thanks to everyone for their active participation.

Best Kind Of Regards, temirg.

[tuxedoxt]

Hello,

as related I'll mention that I noticed similar messages during testing on some systems where there is no .Xauthority file in home.

As this was not covered by the implementation so far https://github.com/tuxedocomputers/tuxedo-control-center/commit/78023da709d47c793fd63d5a57fd9a63483dcb5e now checks if missing and does not attempt to continue.

On systems where the file resides in other place (like /tmp etc.) another solution would be needed. Ultimately the feature will need another solution for wayland anyway.

[temirg]

Hello,

the linked solution: this.xAuthorityFile = "/home/" + username + "/.Xauthority";

is not really good, because there are cases of, for example "/home/$USER/$USER" as standard for creating users in RHEL or other Distributions.

$HOME should be determined dynamically (here an example for C++): https://stackoverflow.com/questions/2910377/get-home-directory-in-linux

Regards, temirg.

[tuxedoxt]

Yeah, there's a number of other locations like /run, /temp that are not covered by the home folder either. Ultimately I guess the problem needs to be turned around into a user service that already has the env specifying where it is, or makes the change directly.