Weird nonprintable characters in log file keep QSI from reading the log completely

[FadeToGrey]

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.

Hm, does not seem so... I switched the default shell back to bash by doing a chsh -s /usr/bin/bash for both my user and the administrator, rebooted... and boot.log contained new instances of those characters. AFAIR shell scripts ought to call "their" shell in the first line anyway (e.g. "#!/bin/bash"), or am I mistaken there?

[fehlix]

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]

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]

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 .

[fehlix]

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?

Maybe post some of those, so we can test, the adjusted "filter" used in QSI?

[FadeToGrey]

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.

boot.log was already attached to the first post, did you see that one? Here are two more - user.log and access_log. syslog and kern.log are a bit painful to check for anything sensible due to their size, therefore I excluded those for now...

[FadeToGrey]

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 .

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)

[timkb4cq]

AFAIR 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]

AFAIR 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.

I understand, but that should be okay here. /bin/sh is still sh (or dash, I admit I do not know the difference of those two), not fish. I quickly learned that makes a difference since I have a 20 year old Cadsoft Eagle PCB router software here and the installer that one uses immediately failed when running in fish after I installed MX.

[fehlix]

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)

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...