logging no longer standard?

[Carl Fink]

Today, on my Bullseye system, X crashed and restarted. Naturally, I
thought I'd check my logs to see if I could find out why.

Well, no ... because syslog does not exist.

Is it really the default to have no/very little logging when using
mostly the default install? (I just installed syslog-ng, now that I know
that I have to.)

-Carl Fink

[to...@tuxteam.de]

Under systemd the default is the systemd journal, yes.

That said, if you are looking for the X11 logs, perhaps they are
elsewhere and not under the journalctll umbrella anyway. Someone
with systemd knowledge might chime in.

Cheers
--
t

[Michel Verdier]

On 2023-08-04, Carl Fink wrote:

> Today, on my Bullseye system, X crashed and restarted. Naturally, I thought
> I'd check my logs to see if I could find out why.
>
> Well, no ... because syslog does not exist.

If you don't have syslog your logs will be on journald.
But X logs could be in /var/log/Xorg.0.log or
~/.xsession-error or ~/.local/share/xorg/Xorg.0.log

[Carl Fink]

It is highly probable that I'm being grumpy because Debian changed
something that
I was used to for decades, without my realizing it. I'm more interested
in *using* my
computer than learning whole new paradigms about, say, logging. Changing
things
will *always* be perceived as friction unless someone explains clearly
why it makes
sense, to me personally.

-Carl Fink

[Brian]

Does this clarify?

https://wiki.debian.org/Rsyslog#Deprecation_in_Bookworm

[Greg Wooledge]

On Sat, Aug 05, 2023 at 08:56:36AM -0400, Carl Fink wrote:
> It is highly probable that I'm being grumpy because Debian changed something
> that
> I was used to for decades, without my realizing it. I'm more interested in
> *using* my
> computer than learning whole new paradigms about, say, logging. Changing
> things
> will *always* be perceived as friction unless someone explains clearly why
> it makes
> sense, to me personally.

You're unlikely to get a satisfactory explanation. My best guess is they
(the Debian developers in question) think systemd's journal is really
neat-o and they want people to consider it the primary information source,
with human-readable text files being "legacy". (To be fair, log rotation
of text files is clunky. But it's a well-understood problem with well-
establish solutions.)

My second best guess is they wanted to reduce redundancy. Having the
same information logged in multiple places might seem unappealing to
them.

In any case, this is not a popular change. I don't remember ever
hearing a single person say "Wow, I'm so glad they did this!" I've
seen many complaints. Most often, people just (re)install rsyslog and
move on with their lives as before.

I will also point out that this change is well-documented, both in the
official release notes[1] and in the wiki.[2] Reading these resources
before an upgrade is highly recommended.

[1] https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#upgrade-specific-issues
[2] https://wiki.debian.org/NewInBookworm

[Greg Wooledge]

On Sat, Aug 05, 2023 at 02:12:31PM +0100, Brian wrote:
> Does this clarify?
>
> https://wiki.debian.org/Rsyslog#Deprecation_in_Bookworm

Ah, I didn't know about that page. It links to bug #1018788 which
says, among other things,

The main reason here is, that I want to avoid that log data is stored
twice on disk.

That's good to know, I suppose.

[err...@free.fr]

I have syslog, and journald.
about having syslog, it is probably because I install rsyslog on all my computers (to send logs on server through vpn).
about having journald, I dont apreciate it, because it change many things that already working for years.
the ONLY avantage (in my opinion) to journald is to start loging very earlier at boot.

may be installing rsyslog is a solution for you (even if you don't need to send logs on a remote server)

[Teemu Likonen]

* 2023-08-05 09:23:25-0400, Greg Wooledge wrote:

> In any case, this [systemd journal] is not a popular change. I don't

> remember ever hearing a single person say "Wow, I'm so glad they did
> this!" I've seen many complaints. Most often, people just (re)install
> rsyslog and move on with their lives as before.

The popularity and opinions haven't been queried. We don't hear people's
silent satisfaction. You only hear complaints and surprise reactions:
"What? Things have changed?"

Ok, here is one: I think systemd is wonderful system and its journal is
really nice part of it. I use systemd units in such way that would have
been difficult before.

--
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462

[Andy Smith]

Hello,

On Sat, Aug 05, 2023 at 08:56:36AM -0400, Carl Fink wrote:

> It is highly probable that I'm being grumpy because Debian changed
> something that I was used to for decades, without my realizing it.

…because you didn't read the release notes that are absolutely
required reading to understand what important things have changed in
Debian at each release.

> Changing things will *always* be perceived as friction unless
> someone explains clearly why it makes sense, to me personally.

So a project needs to come and find you, a person who does not read
their release notes, to advocate to you why any and every change
will be made and seek your approval?

That doesn't sound like a very reasonable thing to ask of
volunteers. Have you considered paying some software developers to
make an OS to your exact specifications without you having to spend
any effort having input except when they consult you?

Thanks,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

[Andy Smith]

Hello,

On Sat, Aug 05, 2023 at 09:23:25AM -0400, Greg Wooledge wrote:
> In any case, this is not a popular change.

I don't think that's clear. I think that amongst a population of
people who care deeply about logging it's generally unfavourable,
and I myself don't particularly enjoy using journalctl so I'd kind
of sort of put myself in that category except you know what? I just
can't bring myself to get worked up over it.

I think that the vast majority of Debian users just do not care
(or even know) and are content using journalctl.

For those of us who do care, installing rsyslog takes seconds.
Disabling the systemd journal (if you want to)_ takes another few
seconds. This email took longer.

As such I'd file it as a reasonable change that I'm not 100% happy
about and has resulted in a couple of extra lines in the Ansible
playbook I use to provision machines. I don't think about it until
the next time there is a thread of people getting bent out of shape
over it.

Whether on balance it is net positive or net negative I don't know.

> I will also point out that this change is well-documented, both in the
> official release notes[1] and in the wiki.[2] Reading these resources
> before an upgrade is highly recommended.

The release notes in particular are essential reading since
otherwise a person won't know about major components that have
changed, been replaced etc.

Cheers,

Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

"The electric guitar - like making love - is much improved by a little
feedback, completely ruined by too much." — The League Against Tedium

[Joe]

On Sat, 5 Aug 2023 15:09:41 +0000
Andy Smith <an...@strugglers.net> wrote:

> Hello,
>
> On Sat, Aug 05, 2023 at 09:23:25AM -0400, Greg Wooledge wrote:
> > In any case, this is not a popular change.
>
> I don't think that's clear. I think that amongst a population of
> people who care deeply about logging it's generally unfavourable,
> and I myself don't particularly enjoy using journalctl so I'd kind
> of sort of put myself in that category except you know what? I just
> can't bring myself to get worked up over it.
>
> I think that the vast majority of Debian users just do not care
> (or even know) and are content using journalctl.
>
> For those of us who do care, installing rsyslog takes seconds.
> Disabling the systemd journal (if you want to)_ takes another few
> seconds. This email took longer.

But will the syslogs continue 'for the foreseeable future' or are there
already plans to drop them from Debian?

>
> As such I'd file it as a reasonable change that I'm not 100% happy
> about and has resulted in a couple of extra lines in the Ansible
> playbook I use to provision machines. I don't think about it until
> the next time there is a thread of people getting bent out of shape
> over it.
>
> Whether on balance it is net positive or net negative I don't know.
>
> > I will also point out that this change is well-documented, both in
> > the official release notes[1] and in the wiki.[2] Reading these
> > resources before an upgrade is highly recommended.
>
> The release notes in particular are essential reading since
> otherwise a person won't know about major components that have
> changed, been replaced etc.

Indeed, but they just tell us *what* stuff has changed, The job of
finding out what has to be actually done in order to continue doing
whatever we do, still has to be done, and that's time wasted. Obviously
things have to change, but backwards compatibility is very important to
minimise such wasted time, as far as possible.

I'm not a professional, I've just run a home/small business server
starting with sarge, and I consider that system administration time
could be better spent either working or playing.

In this fairly minor case, for example, I use 'tail -f <log>' at least
once a week, mainly on syslog itself, debug (where my firewall logs
to), daemon and exim4/mainlog. I'm sure there is a way to do this with
systemd, but it's something else to learn, a bit more running just to
stay still.

--
Joe

[Greg Wooledge]

On Sat, Aug 05, 2023 at 08:03:27PM +0100, Joe wrote:
> On Sat, 5 Aug 2023 15:09:41 +0000
> Andy Smith <an...@strugglers.net> wrote:
> > The release notes in particular are essential reading since
> > otherwise a person won't know about major components that have
> > changed, been replaced etc.
>
> Indeed, but they just tell us *what* stuff has changed, The job of
> finding out what has to be actually done in order to continue doing
> whatever we do, still has to be done, and that's time wasted.

In some cases, the release notes actually do tell you how to get back
to normal.

Where they don't, the wiki almost always does. At least, the changes
that *I* make to it place a very high priority on providing simple,
clear instructions for how to adapt to Debian's changes. Obviously I
can't speak for every wiki editor, but that's kinda the point. The
wiki is *our* resource for sharing solutions with each other.

[Andy Smith]

Hello,

On Sat, Aug 05, 2023 at 08:03:27PM +0100, Joe wrote:

> On Sat, 5 Aug 2023 15:09:41 +0000
> Andy Smith <an...@strugglers.net> wrote:
> > For those of us who do care, installing rsyslog takes seconds.
> > Disabling the systemd journal (if you want to)_ takes another few
> > seconds. This email took longer.
>
> But will the syslogs continue 'for the foreseeable future' or are there
> already plans to drop them from Debian?

For syslog to be gone from Debian, every maintainer of every syslog
implementation would have to decide to abandon their work. As these
are very popular packages, that does not seem likely.

I suppose it could happen though, if journald got all the features
of every syslogd. Still one of the design goals of journald was the
structured (binary format) logging whereas plain text logging is a
very popular syslog feature, so that still doesn't seem likely.

Who can tell though? It all rests on individuals wanting to do the
work in Debian.

> > The release notes in particular are essential reading since
> > otherwise a person won't know about major components that have
> > changed, been replaced etc.
>
> Indeed, but they just tell us *what* stuff has changed, The job of
> finding out what has to be actually done in order to continue doing
> whatever we do, still has to be done, and that's time wasted. Obviously
> things have to change, but backwards compatibility is very important to
> minimise such wasted time, as far as possible.

Have you actually read the part of the Debian release notes we're
talking about? I seem to recall them being very clear. journalctl is
very well documented. And if you prefer then it only takes a few
seconds to install rsyslog at which point logging is exactly like it
was in the previous release.

It's really hard for me to see this as a big deal. I don't know what
Debian could have done better, since pleasing all of the people all
of the time isn't a realistic option.

If you DO have good ideas for improvement, by the way, it is
possible to submit patches to the release notes. I've had a couple
of minor things accepted post-release. It's definitely a living
document. So something positive can be contributed.

> it's something else to learn, a bit more running just to stay
> still.

I don't know what to say to you. Computer use just doesn't stay
static. There isn't a single product, platform, operating system,
application or really ANYTHING in computing that I could point you
to that doesn't change.

The idea that it's "just to stay still" is similar to saying it is
"just change for change's sake", which is a common complaint when
confronted by change that we don't approve of. It does happen to a
degree, for sure - developers prefer making new things than they do
perfecting old things. Twenty years ago Jamie Zawinsky called Linux
a Cadre of Attention-Deficit Teenagers:
<https://www.jwz.org/doc/cadt.html>. But most changes are done
because someone somewhere sees value in them. Even if you or I don't
always particularly appreciate it the way that they do.

Thanks,

Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

Please consider the environment before reading this e-mail.
— John Levine

[Max Nikulin]

On 06/08/2023 02:03, Joe wrote:
> I use 'tail -f <log>' at least
> once a week

journalctl -f

[Henning Follmann]

On Sat, Aug 05, 2023 at 03:12:39PM -0400, Greg Wooledge wrote:
> On Sat, Aug 05, 2023 at 08:03:27PM +0100, Joe wrote:
> > On Sat, 5 Aug 2023 15:09:41 +0000
> > Andy Smith <an...@strugglers.net> wrote:
>

[...]

> In some cases, the release notes actually do tell you how to get back
> to normal.

err,
"how to get back."
Normal is the new systemd

SCNR :)

-H

--
Henning Follmann | hfol...@itcfollmann.com

[gene heskett]

On 8/7/23 07:50, Henning Follmann wrote:
> On Sat, Aug 05, 2023 at 03:12:39PM -0400, Greg Wooledge wrote:
>> On Sat, Aug 05, 2023 at 08:03:27PM +0100, Joe wrote:
>>> On Sat, 5 Aug 2023 15:09:41 +0000
>>> Andy Smith <an...@strugglers.net> wrote:
>>
> [...]
>> In some cases, the release notes actually do tell you how to get back
>> to normal.
> err,
> "how to get back."
> Normal is the new systemd
>

And the new logging is journal.d or some such. And I so far have not
been able to detect from reading its tail equ, what port of which card
is WHICH PHYSICAL DRIVE? Logging is IMO incomplete until I can easily
locate the drive plugged into sata 4 or 5, starting at base 0, of the
2nd sata controller plugged into my machine. If its there, but I can't
see it, explain to ME how to make that connection. The log is full of
info but gives virtually zero clues for stuff that's locking this
machine up tight, so tight it takes 2 minutes to register that the front
panels reset button has been pressed. A digiKam AppImage cannot open and
write an output file to my raid10 /home partitian. However the database
can write its files A Cura AppImage waits for around 2 minutes to open
an output file requestor, presumably because the default path is into my
raid10. If in my impatience, I click save to disk a second time, Its a
50-50 bet I'll wind up using a root session of htop to kill it and start
all over again.

Absolutely none of that makes it to the log I can read with sudo.

This causes me to ask about any new ACL's bookworm might have put in
place, but questions about that have so far been totally ignored. I
according to an ls -lR, own that raid10 lock, stock and barrel, so why
can't apps running as me, write to it without the 2 minute wait? And
why is there no d------ clue in the logs root can read, showing why this
is happening.

All most of you can do is give Gene more hell, he broke it again. W/o
telling me what I actually did wrong. The 4 main apps I use, 3 of them
are AppImages because they are under constant development, and the
version supplied is old & slow. OpenSCAD is 2+ years old in the repo's,
the current AppImage is now around 8 releases newer, quite a bit more
complete AND at least 10x faster. Same for cura, yours is many versions
out of date. 4.13 vs 5.4.0. And I've checked, the repo version also has
this same blockage. Why? What log can I look at that might actually TELL
me something?

All I can see in journalctl's log is gigabytes spewed by plasmashell,
and which I can't find what its REAL name is as I generally use konsole
for a terminal screen. Sample:

ug 07 09:11:07 coyote plasmashell[2385]: Could not find the Plasmoid for
Plasma::FrameSvgItem(0x559c2dbc5990) QQmlContext(0x559c29de8860)
QUrl("file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/global/Globals.qml")
Aug 07 09:13:55 coyote kwin_x11[2346]: kwin_core: XCB error: 3
(BadWindow), sequence: 15618, resource id: 32931609, major code: 129
(SHAPE), minor code: 6 (Input)
Aug 07 09:13:55 coyote kwin_x11[2346]: qt.qpa.xcb: QXcbConnection: XCB
error: 3 (BadWindow), sequence: 15619, resource id: 32931609, major
code: 2 (ChangeWindowAttributes), minor code: 0
Aug 07 09:20:03 coyote plasmashell[2385]: Could not find the Plasmoid
for Plasma::FrameSvgItem(0x559c2da12130) QQmlContext(0x559c29de8860)
QUrl("file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/global/Globals.qml")
Aug 07 09:20:03 coyote plasmashell[2385]: Could not find the Plasmoid
for Plasma::FrameSvgItem(0x559c2da12130) QQmlContext(0x559c29de8860)
QUrl("file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/global/Globals.qml")
Aug 07 09:20:08 coyote kwin_x11[2346]: qt.qpa.xcb: QXcbConnection: XCB
error: 3 (BadWindow), sequence: 61182, resource id: 44044366, major
code: 15 (QueryTree), minor code: 0
Aug 07 09:26:11 coyote plasmashell[2385]: Could not find the Plasmoid
for Plasma::FrameSvgItem(0x559c2d983bd0) QQmlContext(0x559c29de8860)
QUrl("file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/global/Globals.qml")
Aug 07 09:26:11 coyote plasmashell[2385]: Could not find the Plasmoid
for Plasma::FrameSvgItem(0x559c2d983bd0) QQmlContext(0x559c29de8860)
QUrl("file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/global/Globals.qml")
Aug 07 09:29:13 coyote plasmashell[2385]: Could not find the Plasmoid
for Plasma::FrameSvgItem(0x559c2da372e0) QQmlContext(0x559c29de8860)
QUrl("file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/global/Globals.qml")
Aug 07 09:29:13 coyote plasmashell[2385]: Could not find the Plasmoid
for Plasma::FrameSvgItem(0x559c2da372e0) QQmlContext(0x559c29de8860)
QUrl("file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/global/Globals.qml")
Aug 07 09:34:31 coyote kwin_x11[2346]: kwin_core: XCB error: 3
(BadWindow), sequence: 28339, resource id: 32949194, major code: 129
(SHAPE), minor code: 6 (Input)
Aug 07 09:34:31 coyote kwin_x11[2346]: qt.qpa.xcb: QXcbConnection: XCB
error: 3 (BadWindow), sequence: 28340, resource id: 32949194, major
code: 2 (ChangeWindowAttributes), minor code: 0
Aug 07 09:34:37 coyote ksmserver[2926]: qt.qpa.xcb: QXcbConnection: XCB
error: 3 (BadWindow), sequence: 15362, resource id: 16780529, major
code: 18 (ChangeProperty), minor code: 0
Aug 07 09:34:37 coyote ksmserver[2926]: qt.qpa.xcb: QXcbConnection: XCB
error: 3 (BadWindow), sequence: 15363, resource id: 16780529, major
code: 18 (ChangeProperty), minor code: 0
Aug 07 09:34:49 coyote kwin_x11[2346]: kwin_core: XCB error: 3
(BadWindow), sequence: 32066, resource id: 32949507, major code: 129
(SHAPE), minor code: 6 (Input)
Aug 07 09:34:49 coyote kwin_x11[2346]: qt.qpa.xcb: QXcbConnection: XCB
error: 3 (BadWindow), sequence: 32067, resource id: 32949507, major
code: 2 (ChangeWindowAttributes), minor code: 0
Aug 07 09:35:11 coyote plasmashell[2385]: Could not find the Plasmoid
for Plasma::FrameSvgItem(0x559c2daae510) QQmlContext(0x559c29de8860)
QUrl("file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/global/Globals.qml")
Aug 07 09:35:11 coyote plasmashell[2385]: Could not find the Plasmoid
for Plasma::FrameSvgItem(0x559c2daae510) QQmlContext(0x559c29de8860)
QUrl("file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/global/Globals.qml")
Aug 07 09:35:15 coyote kwin_x11[2346]: qt.qpa.xcb: QXcbConnection: XCB
error: 3 (BadWindow), sequence: 38526, resource id: 44044419, major
code: 15 (QueryTree), minor code: 0
Aug 07 09:38:38 coyote kwin_x11[2346]: kwin_core: XCB error: 3
(BadWindow), sequence: 59056, resource id: 32952602, major code: 129
(SHAPE), minor code: 6 (Input)
Aug 07 09:38:38 coyote kwin_x11[2346]: qt.qpa.xcb: QXcbConnection: XCB
error: 3 (BadWindow), sequence: 59057, resource id: 32952602, major
code: 2 (ChangeWindowAttributes), minor code: 0
Aug 07 09:38:39 coyote ksmserver[2926]: qt.qpa.xcb: QXcbConnection: XCB
error: 3 (BadWindow), sequence: 19938, resource id: 16780546, major
code: 18 (ChangeProperty), minor code: 0
Aug 07 09:38:39 coyote ksmserver[2926]: qt.qpa.xc

What for instance, do I install to stop this crap so I might see a real
message?

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

[songbird]

gene heskett wrote:
...

> Absolutely none of that makes it to the log I can read with sudo.
>
> This causes me to ask about any new ACL's bookworm might have put in
> place, but questions about that have so far been totally ignored. I
> according to an ls -lR, own that raid10 lock, stock and barrel, so why
> can't apps running as me, write to it without the 2 minute wait? And
> why is there no d------ clue in the logs root can read, showing why this
> is happening.

have you ever used strace?


songbird

[Henning Follmann]

On Mon, Aug 07, 2023 at 09:41:11AM -0400, gene heskett wrote:
> On 8/7/23 07:50, Henning Follmann wrote:
> > On Sat, Aug 05, 2023 at 03:12:39PM -0400, Greg Wooledge wrote:
> > > On Sat, Aug 05, 2023 at 08:03:27PM +0100, Joe wrote:
> > > > On Sat, 5 Aug 2023 15:09:41 +0000
> > > > Andy Smith <an...@strugglers.net> wrote:
> > >
> > [...]
> > > In some cases, the release notes actually do tell you how to get back
> > > to normal.
> > err,
> > "how to get back."
> > Normal is the new systemd
> >

[deleted rant novella]

Breathe!

Your issues are not solved by or caused by either of journald or rsyslog.
These are just writing what is given to them to somewhere.
If it is not in the log it's someone else's fault.

[gene heskett]

Many times over the last 25 years. However this problem occurs when it
has already output several gigabytes of previous data the shell has
scrolled off the end of th buffer.. There is not a way to have it start
doing the trace when I click on the save to disk button. That would
make 500x more useful as a tracing aid. Or do yu know a trick that
allows that?

Thanks Songbird.
>
> songbird
>
> .

[songbird]

gene heskett wrote:
...

> Many times over the last 25 years. However this problem occurs when it
> has already output several gigabytes of previous data the shell has
> scrolled off the end of th buffer.. There is not a way to have it start
> doing the trace when I click on the save to disk button. That would
> make 500x more useful as a tracing aid. Or do yu know a trick that
> allows that?

set your shell to unlimited or tee it to a file on a big SSD
partition.


songbird

[gene heskett]

Ohhhkaaay, but why then do I get a message if looking at the journal as
user 1000, that the user must be a member of the adm group to see all
the log, AND adding me to the adm group doesn't change what I can see
using sudo? I see gigabytes of stuff from kwin etc, but nary a syllable
from what isn't working because something blocks it.

[gene heskett]

I believe konsole is unlimited by default. On checking in settings, its
not listed. Scrollback is from my /tmp, which would be on my raid10, so
maybe that something else that is blocked from useing my raid10. IDK.
ulimit reports unlimited. And there is 32G of dram available, htop says:
a bit over 2G's in use out of 32G's, 0 swap/30G's available.

[songbird]

gene heskett wrote:
...

> I believe konsole is unlimited by default. On checking in settings, its
> not listed. Scrollback is from my /tmp, which would be on my raid10, so
> maybe that something else that is blocked from useing my raid10. IDK.
> ulimit reports unlimited. And there is 32G of dram available, htop says:
> a bit over 2G's in use out of 32G's, 0 swap/30G's available.

konsole is a kde package so i'm not familiar with it at
all.

i do not use split journal files with systemd so i see
everything combined and use root. i also have rsyslog
installed because at times i like to be able to see
messages in that format.

sudo crap i don't bother with either, that's why there is
root, if i don't want to have root access then i have all
my other terminals set up for my user access only and that's
fine with me.

man journald.conf...


songbird

[gene heskett]

I've looked at that, even looked at the file. It is all systemd
related, no mention of user stuffs. Its as if a 3 meter tall board
fence has been built around the systemd stuff that user apps can't get thru.

Glaringly missing is anything related to something the user might want
to do. So where is an equal facility for user stuffs? Someplace where
an AppImage looking for a missing dependency might express its
displeasure at not finding everything it needs?

[Max Nikulin]

On 08/08/2023 00:35, gene heskett wrote:
> There is not a way to have it start doing the trace when I click on the
> save to disk button.

Really? And certainly --attach/-p option is not a rescue.

Sending output to a file, filtering specific calls, increasing per line
size limit are useless options as well.

I have no idea which way you may break journald and why you have not
just installed rsyslog yet if you trust it more and have a hope to find
there more info than in journalctl output. journalctl has a number
option for filtering: per unit, --system, --user, etc.

However an AppImage may send nothing to the syslog or journald sockets.
stderr might appear e.g. in ~/.xsession-errors

[gene heskett]

On 8/7/23 22:08, Max Nikulin wrote:
> On 08/08/2023 00:35, gene heskett wrote:
>> There is not a way to have it start doing the trace when I click on
>> the save to disk button.
>
> Really? And certainly --attach/-p option is not a rescue.
>
> Sending output to a file, filtering specific calls, increasing per line
> size limit are useless options as well.
>
> I have no idea which way you may break journald and why you have not
> just installed rsyslog yet if you trust it more and have a hope to find
> there more info than in journalctl output. journalctl has a number
> option for filtering: per unit, --system, --user, etc.
>

Show me anyplace in the man page where "--user" occurs, please. Its not
there in my man page.

> However an AppImage may send nothing to the syslog or journald sockets.
> stderr might appear e.g. in ~/.xsession-errors

Hmmm... just a few lines since the last reboot. And might be a clue...

Xsession: X session started for gene at Tue 27 Jun 2023 02:58:23 PM EDT
WARNING: tempfile is deprecated; consider using mktemp instead.
dbus-update-activation-environment: error: unable to connect to D-Bus:
Failed to connect to socket /run/user/1000/bus: Connection refused
localuser:gene being added to access control list
dbus-update-activation-environment: error: unable to connect to D-Bus:
Failed to connect to socket /run/user/1000/bus: Connection refused
dbus-update-activation-environment: error: unable to connect to D-Bus:
Failed to connect to socket /run/user/1000/bus: Connection refused

What fixes that?

And thank you Max.

[Greg Wooledge]

On Mon, Aug 07, 2023 at 10:57:41PM -0400, gene heskett wrote:
> On 8/7/23 22:08, Max Nikulin wrote:
> > I have no idea which way you may break journald and why you have not
> > just installed rsyslog yet if you trust it more and have a hope to find
> > there more info than in journalctl output. journalctl has a number
> > option for filtering: per unit, --system, --user, etc.
> >
> Show me anyplace in the man page where "--user" occurs, please. Its not
> there in my man page.

unicorn:~$ man journalctl | grep -- --user
--user, --system, --directory, and --file options, see below.
--system, --user
Show messages from service of current user (with --user). If
The --user option affects how --unit arguments are treated. See
With --user, all --unit arguments will be converted to match user
messages as if specified with --user-unit.
--user-unit=
troff: <standard input>:1187: warning [p 13, 6.3i]: can't break line

That's 7 instances in my man page, although some of those are apparently
part of "--user-unit".

Of course, all of this is a gigantic red herring. If you have a problem
with something called an "AppImage", whatever the hell that is, the
details are not likely to show up in system logs.

If you don't like journalctl and related things, install rsyslog. It
will take less than a minute, and then your system logging will be back
to normal. You can read the files in /var/log/ just like always.

Meanwhile, you will need to find out where your "AppImage" thing is
actually logging, if indeed it does ANY kind of logging at ALL. It's
probably not using syslog(). Ask people who use the thing in question.
Those people may or may not be on debian-user.

[to...@tuxteam.de]

On Mon, Aug 07, 2023 at 05:32:03PM -0400, gene heskett wrote:

[...]

> Ohhhkaaay, but why then do I get a message if looking at the journal as user
> 1000, that the user must be a member of the adm group to see all the log,

...unless you use sudo.

> AND adding me to the adm group doesn't change what I can see using sudo? I

As sudo you can see *all* (I don't know a lot about systemd's journal, but

I do some sysadmin for food, and the boxes at work do systemd, so the basic
knowledge is there. And the above belongs to the basic knowledge.

Now let's be scientific: what evidence makes you assume that there's anything
in the logs you are not shown?

> see gigabytes of stuff from kwin etc, but nary a syllable from what isn't
> working because something blocks it.

Perhaps "what isn't working" isn't logging to the syslogs at all? (this
hunch has come up elsewhere in this thread). Another possibility: it is
in the logs, but hidden under so much stuff that you don't see it.

See, if you "do" AppImages you are multiplying your system's complexity.
Each AppImage is like a little operating system (without the kernel) where
the application provider dictates the rules, not Debian (that's why I
avoid them like the plague).

Cheers
--
t

[Henning Follmann]

I have no idea what is going on on your system. The history of this
mailing list is littered with threads where you do things the "Gene" way and
shooting yourself in the foot. I just assume it's another one.

I am out of this subthread.

[gene heskett]

There are rather copius msgs output to the shell windows that launch
them, Connecting those msgs to the name of a package to install to fix
that, doesn't seem possible. It will name a function call that reports
the error, but not the package containing that function.

digikam for example, does report what I assume is the package name, just
running it, reports a couple screens full of Exiv2 errors, but Exiv2 is
installed. It cannot write to my raid. Shotwell just does it, but in a
format digikam can't see, buried in a directory structure based on the
date/time it was done. Less than helpful.

Thanks Greg.

[gene heskett]

On 8/8/23 00:51, to...@tuxteam.de wrote:
> On Mon, Aug 07, 2023 at 05:32:03PM -0400, gene heskett wrote:
>
> [...]
>
>> Ohhhkaaay, but why then do I get a message if looking at the journal as user
>> 1000, that the user must be a member of the adm group to see all the log,
>
> ...unless you use sudo.
>
>> AND adding me to the adm group doesn't change what I can see using sudo? I
>
> As sudo you can see *all* (I don't know a lot about systemd's journal, but
>
> I do some sysadmin for food, and the boxes at work do systemd, so the basic
> knowledge is there. And the above belongs to the basic knowledge.
>
> Now let's be scientific: what evidence makes you assume that there's anything
> in the logs you are not shown?
>
>> see gigabytes of stuff from kwin etc, but nary a syllable from what isn't
>> working because something blocks it.
>
> Perhaps "what isn't working" isn't logging to the syslogs at all? (this
> hunch has come up elsewhere in this thread). Another possibility: it is
> in the logs, but hidden under so much stuff that you don't see it.

And neither does grep.

> See, if you "do" AppImages you are multiplying your system's complexity.
> Each AppImage is like a little operating system (without the kernel) where
> the application provider dictates the rules, not Debian (that's why I
> avoid them like the plague).

And that's sad, Tomas. The current, nominally 7 day old AppImage of
OpenSCAD can load and render a complex gfx design in seconds. the repo
version, dated from 2021, takes around an hour. You are missing out on
some seriously improved code. ditto for cura and digikam. Running
kiauh.sh at least weekly does the job of keeping klipper, mainsail and
moonraker for 3d printing uptodate, its working great but is being
developed daily. Klipper is learning how to drive a printer fast w/o
making its frame ring like a bell, which you see as ripples in the
surface of something printed after some feature of the print has changed
the direction of the print heads travel. And because it is all web
based, I can run that printer from a web browser on any other machine on
my local net and watch the print being built in real time w/o a camera.
All the heavy lifting is being done on an $85 bananapi. If and when I
get done with the current rebuilds in progress, there will be 5
bananapi's running a 5 printer farm. There are already 4 other machines
here running the master version of linuxcnc which will in time become
linuxcnc v3.0. If I don't miss roll call first. Parts are being made on
one printer to fix the others.
>
> Cheers

[to...@tuxteam.de]

On Tue, Aug 08, 2023 at 10:33:04AM -0400, gene heskett wrote:
> On 8/8/23 00:51, to...@tuxteam.de wrote:

[...]

> > See, if you "do" AppImages you are multiplying your system's complexity.

[...]

> And that's sad, Tomas. The current, nominally 7 day old AppImage of

> OpenSCAD can load and render a complex gfx design in seconds [...]

It may be, but that's how things are in life: you can chose between
solid, stable and tested *and* playing well with the rest of the
system -- or new & shiny, with the latest bells, whistles and the
occasional built in fireworks. The latter is called "bleeding edge"
for a reason.

Engineering tradeoffs and that.

[I skimmed the rest of your post but decided to leave it at that:
I can't deal with that many things at once]

Cheers
--
t

[songbird]

gene heskett wrote:
>songbird wrote:
...

>> man journald.conf...
>
> I've looked at that, even looked at the file. It is all systemd
> related, no mention of user stuffs. Its as if a 3 meter tall board
> fence has been built around the systemd stuff that user apps can't get thru.

no, i was just pointing out that i find the combined logs
of systemd a lot easier to deal with as root instead of trying
to look at them as a user and having them broken apart. for a
simple system that i run it makes little sense to complicate
things by having separate logs in systemd journal.

> Glaringly missing is anything related to something the user might want
> to do. So where is an equal facility for user stuffs? Someplace where
> an AppImage looking for a missing dependency might express its
> displeasure at not finding everything it needs?

i'm light years behind App[Anything]. once you mix up
what a system is doing then that adds yet more complexity
which like i mentioned above i tend to not do if i can
help it.

IMO once you've started installing things from a vendor's
repository you've then got to figure out how that integrates
or not with your package management system. the most of
that which i do here is in Python and i use virtual
environments to try to isolate the problem children to where
i hope they won't mess up the rest of my Python install. so
far that seems to be working as intended.

i'm sorry i can't help much...


songbird

[debia...@howorth.org.uk]

gene heskett <ghes...@shentel.net> wrote:
> Someplace where an AppImage looking for a missing dependency might
> express its displeasure at not finding everything it needs?

I've always thought that was a main advantage of starting anything from
the command line - there's an obvious place for the output - the
terminal.

[gene heskett]

> .
And much of the time, the errors reported there seem to reference
something that does not hit a search in synaptic. I've posted several
kilobytes of that w/o getting a helpful comment. Something along the
lines of "oh, that's part of pkg so and so would be most helpful.

I'd say thank you if I had a name.

[Max Nikulin]

On 08/08/2023 09:57, gene heskett wrote:
> Xsession: X session started for gene at Tue 27 Jun 2023 02:58:23 PM EDT

^^^^^^^^^^^^^^^

> dbus-update-activation-environment: error: unable to connect to D-Bus:
> Failed to connect to socket /run/user/1000/bus: Connection refused
>
> What fixes that?

These messages might be old, but they might mean that you broke D-Bus.
Applications, especially self-containing packages, may heavily rely on
its availability.

Try to figure out at which moment such messages appear. Try "busctl
--user" and "busctl --user status" as a sanity check.

[Max Nikulin]

On 08/08/2023 19:07, gene heskett wrote:
> digikam for example, does report what I assume is the package name, just
> running it, reports a couple screens full of Exiv2 errors, but Exiv2 is
> installed.

I have an impression that properly built AppImage should come with all
necessary libraries included and should not rely on packages installed
in the system.

Your camera and EXIF parsing library may have different notion on EXIF
tags format and allowed values. You may discuss whether the errors are
critical with developers or packagers of the applications and to filter
out these errors otherwise.

[gene heskett]

Both of those get somewhat copious outputs, what should I be looking
for? Should it name the app?
>
Looking in /etc/dbus-1, I see two dirs, one of which is empty:

gene@coyote:/etc/dbus-1$ ls -R
.:
session.d system.d

./session.d:

./system.d:
bluetooth.conf
com.ubuntu.SoftwareProperties.conf org.freedesktop.DisplayManager.conf
org.freedesktop.ModemManager1.conf org.opensuse.CupsPkHelper.Mechanism.conf
com.redhat.NewPrinterNotification.conf dnsmasq.conf
org.freedesktop.GeoClue2.Agent.conf
org.freedesktop.PackageKit.conf sddm_org.freedesktop.DisplayManager.conf
com.redhat.PrinterDriversInstaller.conf net.hadess.SensorProxy.conf
org.freedesktop.GeoClue2.conf org.freedesktop.realmd.conf
wpa_supplicant.conf

dbus has always been a puzzle to me. It has no man pages to explain its
functions. Do you want to see the outputs of busctl? Under what conditions?

I see busctl does have a man page. Pretty complex. What should I check next?

Thanks Max.

[gene heskett]

On 8/9/23 21:24, Max Nikulin wrote:
> On 08/08/2023 19:07, gene heskett wrote:
>> digikam for example, does report what I assume is the package name,
>> just running it, reports a couple screens full of Exiv2 errors, but
>> Exiv2 is installed.
>
> I have an impression that properly built AppImage should come with all
> necessary libraries included and should not rely on packages installed
> in the system.
>

We also think about AppImages as complete, satisfying ALL their own
dependencies. No disagreement there. I do see them as huge storage
resource hogs, but at the same time papers over individual system
differences IF done right. FWIW, the repo version of digikam also
suffers the can't write to local storage problem, but its supposedly a
known bug in 7.9 that has since been fixed ack the digikam folks, but
their AppImage builds for version 8.2 still don't work /here/.
That leaves the fact that /home is a raid here, but surely I am not the
only one on the planet doing that.

> Your camera and EXIF parsing library may have different notion on EXIF
> tags format and allowed values. You may discuss whether the errors are
> critical with developers or packagers of the applications and to filter
> out these errors otherwise.

Throw in that we have no control over the camera maker, in all cases
here they are well known, reputable makers of at least 3 cameras that
have saved pix in that tree, plus probably a thou or more of pix saved
from the net in there, I guess its up to us to configure this stuff so
it works. Is there a tut describing how someplace?

cuda is also named in the errors, and none of its dozen or so variations
is installed. Which one to install?

Thank you Max.

[Max Nikulin]

On 10/08/2023 16:53, gene heskett wrote:
> On 8/9/23 21:15, Max Nikulin wrote:
>> On 08/08/2023 09:57, gene heskett wrote:
>>> dbus-update-activation-environment: error: unable to connect to
>>> D-Bus: Failed to connect to socket /run/user/1000/bus: Connection
>>> refused

...

>> Try to figure out at which moment such messages appear. Try "busctl
>> --user" and "busctl --user status" as a sanity check.
>>
> Both of those get somewhat copious outputs, what should I be looking
> for?  Should it name the app?

You can compare usual output of the commands and their output just after
the error message appears. You may get some impression of features
exposed through D-Bus.

> Looking in /etc/dbus-1, I see two dirs, one of which is empty:

What do you expect to find there? Packages put files into
/usr/share/dbus-1. Systemd units may tell that they may be activated
through D-Bus. Applications may express in .desktop files that they
should handle arguments through D-Bus and Exec=... should be ignored.

> dbus has always been a puzzle to me. It has no man pages to explain its
> functions.

There are a lot of docs for particular D-Bus APIs, e.g.
https://www.freedesktop.org/software/systemd/man/org.freedesktop.hostname1.html

If you are looking for some overview and introduction then starting
points may be
https://en.wikipedia.org/wiki/D-Bus
and docs linked from
https://www.freedesktop.org/wiki/Software/dbus/
e.g.
https://www.freedesktop.org/wiki/IntroductionToDBus/

The point is that if some application can not connect to D-Bus then
arbitrary features may be broken. However your error is either extremely
severe since session D-Bus is not running at all or it is almost
harmless since it appears due to some race on login or logout.