MX Linux Forum

FadeToGrey wrote: Tue Feb 04, 2025 3:04 pm The attached bootlog fom a current MX Linux KDE contains some unprintable characters which manage to stop QSI from reading it completely. this one is just an example, it seems to happen at other log files as well, rendering QSI somewhat useless - you need to open the log in /var/log with a text editor to see everything...

Even the KDE clipboard is caused to fail by these characters. In the example file, they occur at the beginning of lines, 53, 61, 90, 125, 133 and 163. QSI and KED clipboard both stop displaying / copying anything after the first occurrence of this character.

Does anyone happen to know where this comes from and how to solve it?

quick-system-info-mx

FadeToGrey wrote: Tue Feb 04, 2025 3:35 pm Sorry, here it is:
This part of QSI works both in command line and in GUI - it's the log files that cause the trouble.

timkb4cq wrote: Tue Feb 04, 2025 4:11 pm I wonder if the issue is using fish as your default shell instead of bash or dash.
Fish isn't fully Posix compliant so some system shell scripts may not be running as intended.

timkb4cq wrote: Tue Feb 04, 2025 4:11 pm I wonder if the issue is using fish as your default shell instead of bash or dash.
Fish isn't fully Posix compliant so some system shell scripts may not be running as intended.

FadeToGrey wrote: Tue Feb 04, 2025 3:59 pm Apart from boot.log I found:

- user.log
- opensnitchd.log (Opensnitch is however nothing you provide, thus I see it als "for sake of completeness only" ;-) )
- syslog
- kern.log
- /cups/access_log

I think that's it - opening each log file in the same instance of Kate lets you search for the character.

Edit: interestingly, in some of those logs there are a lot of those characters an a row - access:log for example contains 184 of those in a row, kern.log has a row of 313 of those...

• boot.log: one between the text "Setting sensors limits..." and "done", one between "Starting cgroup management daemon: cgmanager" and "Setting up console font and keymap...done.", one between "Starting Web Services Dynamic Discovery host daemon: wsdd" and "Starting CUPS Bonjour daemon: cups-browsed."
• user.log: 64 of them in a row between a "shutting down for system reboot" message and an error message regarding zram0 - interestingly that one cannot be reliably repeated, subsequents reboot informations do have the characters between the these two messages
• syslog: a generous amount of 3580 of those characters occurring almost at the same time at the same reboot when the ones in user.log appeared (time stamp in user.log: between 2025-02-04T19:07:55.126367+01:00 and 2025-02-04T19:08:36.845258+01:00, time stamp here: between 2025-02-04T19:07:55.139275+01:00 and 2025-02-04T19:08:36.825676+01:00
• kern.log: once again, one occurrence, 313 in a row, at the same time when the ones in user.log and syslog occurred (between timestamp 2025-02-04T19:07:55.135468+01:00 and 2025-02-04T19:08:36.825676+01:00)
• cups/access_log: and again, one occurrence, 313 in a row, at largely the same time when the ones in user.log and syslog occurred, between [04/Feb/2025:19:07:45 +0100] and [04/Feb/2025:19:08:38 +0100]

fehlix wrote: Tue Feb 04, 2025 4:56 pm

FadeToGrey wrote: Tue Feb 04, 2025 3:59 pm Apart from boot.log I found:

- user.log
- opensnitchd.log (Opensnitch is however nothing you provide, thus I see it als "for sake of completeness only" ;-) )
- syslog
- kern.log
- /cups/access_log

I think that's it - opening each log file in the same instance of Kate lets you search for the character.

Edit: interestingly, in some of those logs there are a lot of those characters an a row - access:log for example contains 184 of those in a row, kern.log has a row of 313 of those...

Maybe could you post some of those, which do not have any sensible data, unmodyfied.
I mean not the one shown by QSI, if they got shown. But the files directly from /var/log...
e.g move/add those into a zip-archive and attach the zip to a post. Note in the file-selection window to add an attachment,
you may need change the default filter to *zip (or all) files. There is a size limit, so choose small ones.

FadeToGrey wrote: Tue Feb 04, 2025 5:14 pm if it helps, here is a list of all the occurrences I found so far:

• boot.log: one between the text "Setting sensors limits..." and "done", one between "Starting cgroup management daemon: cgmanager" and "Setting up console font and keymap...done.", one between "Starting Web Services Dynamic Discovery host daemon: wsdd" and "Starting CUPS Bonjour daemon: cups-browsed."
• user.log: 64 of them in a row between a "shutting down for system reboot" message and an error message regarding zram0 - interestingly that one cannot be reliably repeated, subsequents reboot informations do have the characters between the these two messages
• syslog: a generous amount of 3580 of those characters occurring almost at the same time at the same reboot when the ones in user.log appeared (time stamp in user.log: between 2025-02-04T19:07:55.126367+01:00 and 2025-02-04T19:08:36.845258+01:00, time stamp here: between 2025-02-04T19:07:55.139275+01:00 and 2025-02-04T19:08:36.825676+01:00
• kern.log: once again, one occurrence, 313 in a row, at the same time when the ones in user.log and syslog occurred (between timestamp 2025-02-04T19:07:55.135468+01:00 and 2025-02-04T19:08:36.825676+01:00)
• cups/access_log: and again, one occurrence, 313 in a row, at largely the same time when the ones in user.log and syslog occurred, between [04/Feb/2025:19:07:45 +0100] and [04/Feb/2025:19:08:38 +0100]

This means: apart from the occurrences in boot.log, these characters seem to be connected to a reboot done because of MX Linux loosing its grip on any sound devices (both sound card, Nvidia HDA and bluetooth connector for my headphones) - which again seems to be triggered by my KVM switch if the computer is inactive but running for an extended period of time. Wonderful... some kind of uncaught timeout error entry while waiting for the device?

fehlix wrote: Tue Feb 04, 2025 4:56 pm

FadeToGrey wrote: Tue Feb 04, 2025 3:59 pm Apart from boot.log I found:

- user.log
- opensnitchd.log (Opensnitch is however nothing you provide, thus I see it als "for sake of completeness only" ;-) )
- syslog
- kern.log
- /cups/access_log

I think that's it - opening each log file in the same instance of Kate lets you search for the character.

Edit: interestingly, in some of those logs there are a lot of those characters an a row - access:log for example contains 184 of those in a row, kern.log has a row of 313 of those...

Maybe could you post some of those, which do not have any sensible data, unmodyfied.
I mean not the one shown by QSI, if they got shown. But the files directly from /var/log...
e.g move/add those into a zip-archive and attach the zip to a post. Note in the file-selection window to add an attachment,
you may need change the default filter to *zip (or all) files. There is a size limit, so choose small ones.

fehlix wrote: Tue Feb 04, 2025 5:17 pm

fehlix wrote: Tue Feb 04, 2025 4:56 pm

FadeToGrey wrote: Tue Feb 04, 2025 3:59 pm Apart from boot.log I found:

- user.log
- opensnitchd.log (Opensnitch is however nothing you provide, thus I see it als "for sake of completeness only" ;-) )
- syslog
- kern.log
- /cups/access_log

I think that's it - opening each log file in the same instance of Kate lets you search for the character.

Edit: interestingly, in some of those logs there are a lot of those characters an a row - access:log for example contains 184 of those in a row, kern.log has a row of 313 of those...

Maybe could you post some of those, which do not have any sensible data, unmodyfied.
I mean not the one shown by QSI, if they got shown. But the files directly from /var/log...
e.g move/add those into a zip-archive and attach the zip to a post. Note in the file-selection window to add an attachment,
you may need change the default filter to *zip (or all) files. There is a size limit, so choose small ones.

I tried you log.file you posted in #1 it doesn't crash. OK some "chars" like "null"-char/bytes are not properly filtered.
But no crash .

FadeToGrey wrote: Tue Feb 04, 2025 4:40 pmAFAIR shell scripts ought to call "their" shell in the first line anyway (e.g. "#!/bin/bash"), or am I mistaken there?

timkb4cq wrote: Tue Feb 04, 2025 5:31 pm

FadeToGrey wrote: Tue Feb 04, 2025 4:40 pmAFAIR shell scripts ought to call "their" shell in the first line anyway (e.g. "#!/bin/bash"), or am I mistaken there?

If you check the system scripts in /etc/init.d you'll see that most of them begin #! /bin/sh or #! /bin/sh -e
They expect /bin/sh to be set to a Posix compliant shell. It defaults to dash in MX-23. Fish is intentionally not Posix compliant. Variables are handled differently. Output from bash scripts will differ from what's expected because of that. Backticks don't work. There are still a number of init.d scripts that use backticks to execute commands. Export doesn't work for environment variables. Some system scripts use that.

I'm not saying I know for certain that fish is the cause of your issues - but I do know the output of some system scripts won't be the same when run with fish, and some of that incorrect output may already be saved in conf files that are still being used.

FadeToGrey wrote: Tue Feb 04, 2025 5:26 pm

fehlix wrote: Tue Feb 04, 2025 5:17 pm

fehlix wrote: Tue Feb 04, 2025 4:56 pm
Maybe could you post some of those, which do not have any sensible data, unmodyfied.
I mean not the one shown by QSI, if they got shown. But the files directly from /var/log...
e.g move/add those into a zip-archive and attach the zip to a post. Note in the file-selection window to add an attachment,
you may need change the default filter to *zip (or all) files. There is a size limit, so choose small ones.

I tried you log.file you posted in #1 it doesn't crash. OK some "chars" like "null"-char/bytes are not properly filtered.
But no crash .

No, it does not crash. It simply discards everything behind the first of those characters. Check the amount of lines you can see in QSI and in a text editor.

(Edit: since the log files on my computer usually survive several days before they are replaced by a new file, this means QSI often does not show the current log at all)

fehlix wrote: Tue Feb 04, 2025 5:41 pm

FadeToGrey wrote: Tue Feb 04, 2025 5:26 pm

fehlix wrote: Tue Feb 04, 2025 5:17 pm
I tried you log.file you posted in #1 it doesn't crash. OK some "chars" like "null"-char/bytes are not properly filtered.
But no crash .

No, it does not crash. It simply discards everything behind the first of those characters. Check the amount of lines you can see in QSI and in a text editor.

(Edit: since the log files on my computer usually survive several days before they are replaced by a new file, this means QSI often does not show the current log at all)

Yes, sorry I meant not displaying properly. So thanks for the other logs. Just to make sure we not only"fixing" the null-byte issue...

FadeToGrey wrote: Tue Feb 04, 2025 5:26 pm No, it does not crash. It simply discards everything behind the first of those characters. Check the amount of lines you can see in QSI and in a text editor.

timkb4cq wrote: Tue Feb 04, 2025 5:31 pm I'm not saying I know for certain that fish is the cause of your issues - but I do know the output of some system scripts won't be the same when run with fish, and some of that incorrect output may already be saved in conf files that are still being used.

,,,Just to make sure we not only"fixing" the null-byte issue...

DukeComposed wrote: Tue Feb 04, 2025 5:58 pm

FadeToGrey wrote: Tue Feb 04, 2025 5:26 pm No, it does not crash. It simply discards everything behind the first of those characters. Check the amount of lines you can see in QSI and in a text editor.

Since the early days of UNIX, the null byte (0x00) was used to represent the end of a string. Because UNIX (and the Linux kernel) is written in C, and since C does not have a string datatype, text in C software is at its most basic level represented as a character array, often just a pointer to a spot in memory, with ASCII characters.

It's a little like being told to turn to a random page in a book and start reading, but not being told when to stop reading. Without being given an instruction like "Turn to page 52, and read ten words", a computer would normally just start at page 52 and read to the end of the book. And then crash because it ran out of things to read.

The null byte tells most C software to stop reading. It functions a little like a period in that regard, so your eyes have a logical place to know that the sentence has finished. This has problems, though, if something comes after the period, like if you were reading a sentence about U. S. history or P. D. Q. Bach.

If I were writing a naïve text parser, I'd write one that opened the file, looked for a newline (0x0a), and printed everything up to the newline or null byte, and then look for another newline.

timkb4cq wrote: Tue Feb 04, 2025 5:31 pm I'm not saying I know for certain that fish is the cause of your issues - but I do know the output of some system scripts won't be the same when run with fish, and some of that incorrect output may already be saved in conf files that are still being used.

As a regular fish-shell user on multiple machines since the MX-19 days, I can state that my choice of shell has never had an effect on log files in /var/log. Granted, I leave the built-in scripts alone. When I write system scripts, I use #!/bin/sh as nature intended or, sometimes, execlineb.

juwido wrote: Tue Feb 04, 2025 5:59 pm

,,,Just to make sure we not only"fixing" the null-byte issue...

there are ESC in as well...

------------ Sat Feb 01 20:36:08 PST 2025 ------------
INIT: version 3.06 booting
INIT: No inittab.d directory found
Using makefile-style concurrent boot in runlevel S.
Starting hotplug events dispatcher: systemd-udevd.

[snip]

Cleaning up temporary files....
Starting Setting kernel variables: sysctl.
Configuring network interfaces in background... 
\0done.
Starting RPC port mapper daemon: rpcbind.
Starting firewall: ufw...Setting kernel variables (/etc/ufw/sysctl.conf)...
\0done.

[snip]

Starting acpi_fakekey daemon...done.
Starting cgroup management daemon: cgmanager
\0Setting up console font and keymap...done.
Starting cgroup management proxy daemon: cgproxy.
Not starting fancontrol; run pwmconfig first. ... [33m(warning).[0m
Not starting NFS kernel daemon: no exports..

FadeToGrey wrote: Tue Feb 04, 2025 6:02 pm I also managed to copy the part of the syslog that contains those null characters, please find it attached as well.

By the way, something partially connected for the wish list. It would be great if QSI could translate the Escape-sequences for colours to coloured text as well (such as the

Code: Select all

... [31mfailed![0m

in the boot.log. Is there some place I can suggest that?