Where do console messages show up in RasPiOS?

You could dredge through systemd logs.

It is unclear as to exactly what you are doing. Wjat code is being launched and exactly how?

ssh?

Standard error from applications launched from the desktop historically (and at least to some extent, still) goes to a file in your home directory. Watch it with:

tail -f ~/.xsession-errors

Some things log to the user journal:

journalctl --user --follow

Depending on the cause of the problem the kernel log may also be informative:

journalctl --dmesg --follow

Thank you very much!!

bob prohaska

Unfortunately due an onset of idiocy at Pi towers, starting with Bookworm they chose to remove rsyslog and it's look-at-with-anything textual logs, leaving you with the aberration of journald binary logging and the need to learn the incomprehensible incantations of journalctl.

Luckily you can readily reinstall the righteous rsyslog package, so it works like Linux (and UNIX) is meant to work.

---druck

Or you could run some other distro whose defaults are more to your liking. Gods forbid you might have to make configuration changes afterwards, eh?

Thank you!!!

bob prohaska

I manage 13 (I just counted them) systems of my own running a mix of Raspbian (or whatever it's called now), Debian and a couple of Ubuntu.

I maintain a mercurial repository of the changes I've done in /etc on all of them. One thing in particular is that **all** systems have logging switched from systemd's journal to rsyslog. The same changed /etc/systemd/journald.conf is on all systems and I've installed rsyslog. Job done and it's dead easy to do the same on any new system.

I’m sure that works OK for system logging (except for the timestamp issue).

But remember, the systemd journal works for per-user-session logging, too.

Since I'm the only user 'per-user' logging isn't all that significant. `

RPi OS is following its Debian upstream here.

I don’t recognize the description of journalctl as ‘incomprehensible incantations’. It doesn’t seem any more opaque than most basic Unix commands to me. Comparing old and new:

tail -f /var/log/messages journalctl -f grep wotsit /var/log/messages journalctl | grep wotsit or journalctl -g wotsit less /var/log/messages journalctl grep kernel: /var/log/messages journalctl -k

You might have to spend a couple of minutes skimming ‘journalctl --help’ or some documentation to learn it, but the same was true of tail, grep, etc; you’ve just already done that and got used to it.

If you really want ‘incomprehensible incantations’ try ffmpeg.

Does “righteous” indicate that the attachment to syslog is religious rather than practical?

It is for users of GUI apps, which is most Linux desktop users.

That includes the poster who asked the question that started this thread.

That's the easy stuff, compare journald.conf with logrotate, and then find that half the vacuum options don't even work correctly. I have to manually clean out in-memory logs every few weeks so it doesn't get full, which affects random stuff.

It's just nasty and entirely unnecessary.

Too bloody right, we should have bunt the heretic Peottering at the stake years ago.

---druck

Never had any trouble with the systemd journal. None whatsoever. Whether on client machines (running Debian Stable), or my own (running Debian Unstable).

I suspect the problem is with your distro.

After opening windows with all three commands running I tried to start a program that sometimes fails silently. In this particular case it didn't fail, starting normally. However, no extra output was displayed in any of the monitoring windows. Should I have seen any output from any of these commands during a successful application start?

FWIW, the command run was from the raspberry>accessories menu, it's called owon-vds-tiny and it runs control software for a USB oscilloscope. When run from the command line it emits a considerable flow of status information to the controlling terminal.

I'll keep trying in hopes of capturing a failure event. So far they seem associated with prolonged (days or weeks) of uptime.

Thanks for reading,

bob prohaska

Not necessarily. Some programs are chatty, but often if there’s nothing wrong then there’s no output.

You would expect that to go _somewhere_ when started from a menu, so if you’re not seeing it at all then there’s certainly a question to answer. (It’s possible, though, that it only generates output if connected to a terminal, or that it writes it to some logfile that you don’t currently know about.)

Well bravo, that proves it must be 100% perfect on a sample size of 1.

No, its the same one the vast majority of people use.

I've even had a bug report given the usual Peottering response to the most glaring or errors; "Not a bug - wont fix".

---druck

Sample size of lots more than just 1 machine.

There is no Linux distro that “the vast majority of people use”.

Feel free to link to the bug report, so we can all decide whom to laugh at.

For the very first time an error dialog box appeared yesterday. The formatting looked more like a Windows widget, so I think it probably came from the application, not the system. It reported an "incompatible magic value nnn...nnn in class file java/util/....".

That suggests whatever is going wrong has nothing to do with RasPiOS, so maybe I shouldn't expect anything to show up in system error logs.

There's been an ongoing compatibility problem with the application. When I set up the Pi2 and tried to use the oscilloscop it worked perfectly. After the first RasPiOS update, it stopped working. Moving to a Pi5 with a more up-to-date RasPiOS, it never worked. The application always ran without error but could never connect to the 'scope, even though lsusb reported the 'scope was connected.

On the Pi2 I started with, it gradually emerged that shortly after boot, the program and 'scope worked fine, but after a few days' uptime the whole system became unstable. It looked like the window manager would crash, leaving a black screen, no mouse pointer and sometimes an unresponsive capslock key. Power cycle was the only way out. This behavior seems independent of whether the 'scope software is in use.

The oscilloscop and software seem to work well when they work so it's a bit frustrating. For the time being, I'm baffled.

Thanks for writing!

bob prohaska

Part of a Java library or application is corrupted.

On a Pi, the first guess would be that the SD card is on the way out.