Lately I've been having trouble with Bookworm, on both a Pi5
and a Pi2B (32 bit), in which the Raspberry menu is used to
launch applications but seemingly nothing happens. No error
message pops up, it's as if I never even tried. Presumably
something had a fatal error, but where should I look for
the epitaph?
This happens most often with Firefox and Chromium browsers,
but occasionally happens with things like LX Terminal, which
I'd expect to be more robust.
There doesn't seem to be a /var/log/messages, as I'm accustomed
to checking, and ISTR Windows used a dedicated application for
watching system messages. Is there such a beast in Bookworm?
I haven't yet hooked up a serial console cable but could if that's
the only way to see what happened.
Thanks for reading!
bob prohaska
bp@www.zefox.net writes:
Lately I've been having trouble with Bookworm, on both a Pi5
and a Pi2B (32 bit), in which the Raspberry menu is used to
launch applications but seemingly nothing happens. No error
message pops up, it's as if I never even tried. Presumably
something had a fatal error, but where should I look for
the epitaph?
This happens most often with Firefox and Chromium browsers,
but occasionally happens with things like LX Terminal, which
I'd expect to be more robust.
There doesn't seem to be a /var/log/messages, as I'm accustomed
to checking, and ISTR Windows used a dedicated application for
watching system messages. Is there such a beast in Bookworm?
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
Lately I've been having trouble with Bookworm, on both a Pi5
and a Pi2B (32 bit), in which the Raspberry menu is used to
launch applications but seemingly nothing happens. No error
message pops up, it's as if I never even tried. Presumably
something had a fatal error, but where should I look for
the epitaph?
This happens most often with Firefox and Chromium browsers,
but occasionally happens with things like LX Terminal, which
I'd expect to be more robust.
There doesn't seem to be a /var/log/messages, as I'm accustomed
to checking, and ISTR Windows used a dedicated application for
watching system messages. Is there such a beast in Bookworm?
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.
bp@www.zefox.net writes:
Lately I've been having trouble with Bookworm, on both a Pi5
and a Pi2B (32 bit), in which the Raspberry menu is used to
launch applications but seemingly nothing happens. No error
message pops up, it's as if I never even tried. Presumably
something had a fatal error, but where should I look for
the epitaph?
This happens most often with Firefox and Chromium browsers,
but occasionally happens with things like LX Terminal, which
I'd expect to be more robust.
There doesn't seem to be a /var/log/messages, as I'm accustomed
to checking, and ISTR Windows used a dedicated application for
watching system messages. Is there such a beast in Bookworm?
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
On Thu, 9 Jul 2026 18:40:37 +0100, druck wrote:
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.
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?
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.
One thing in particular is that **all** systems have logging
switched from systemd's journal to rsyslog.
bp@www.zefox.net wrote:
There doesn't seem to be a /var/log/messages, as I'm accustomed
to checking, and ISTR Windows used a dedicated application for
watching system messages. Is there such a beast in Bookworm?
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.
On Fri, 10 Jul 2026 08:42:08 +0100, Chris Green wrote:
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.
One thing in particular is that **all** systems have logging
switched from systemd's journal to rsyslog.
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.
Lawrence D?Oliveiro <ldo@nz.invalid> wrote:
On Fri, 10 Jul 2026 08:42:08 +0100, Chris Green wrote:
One thing in particular is that **all** systems have logging
switched from systemd's journal to rsyslog.
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.
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.
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.
Richard Kettlewell <invalid@invalid.invalid> wrote:
bp@www.zefox.net writes:
Lately I've been having trouble with Bookworm, on both a Pi5
and a Pi2B (32 bit), in which the Raspberry menu is used to
launch applications but seemingly nothing happens. No error
message pops up, it's as if I never even tried. Presumably
something had a fatal error, but where should I look for
the epitaph?
This happens most often with Firefox and Chromium browsers,
but occasionally happens with things like LX Terminal, which
I'd expect to be more robust.
There doesn't seem to be a /var/log/messages, as I'm accustomed
to checking, and ISTR Windows used a dedicated application for
watching system messages. Is there such a beast in Bookworm?
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!!!
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 12 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 27:09:29 |
| Calls: | 220 |
| Files: | 21,512 |
| Messages: | 84,512 |