Re: logging no longer standard?

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

Re: logging no longer standard?

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


.


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 

Re: logging no longer standard?

[gene heskett]

On 8/9/23 21:15, Max Nikulin wrote:

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.


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

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 

Re: logging no longer standard?

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

Re: logging no longer standard?

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

Re: logging no longer standard?

[gene heskett]

On 8/9/23 10:47, debian-u...@howorth.org.uk wrote:

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

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

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 

Re: logging no longer standard?

[debian-user]

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

Re: logging no longer standard?

[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

Re: logging no longer standard?

[tomas]

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


signature.asc
Description: PGP signature

Re: logging no longer standard?

[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


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 

Re: logging no longer standard?

[gene heskett]

On 8/7/23 23:17, Greg Wooledge wrote:

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

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.

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 

Re: logging no longer standard?

[Henning Follmann]

On Mon, Aug 07, 2023 at 05:32:03PM -0400, gene heskett wrote:
> On 8/7/23 13:23, Henning Follmann wrote:
> > 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 +
> > > > > > Andy Smith  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.
> > 
> > -H
> 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.
> 
> Cheers, Gene Heskett.

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.

-H


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

Re: logging no longer standard?

[tomas]

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


signature.asc
Description: PGP signature

Re: logging no longer standard?

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

Re: logging no longer standard?

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

.


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 

Re: logging no longer standard?

[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

Re: logging no longer standard?

[gene heskett]

On 8/7/23 20:00, songbird wrote:

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


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?




   songbird

.


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 

Re: logging no longer standard?

[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

Re: logging no longer standard?

[gene heskett]

On 8/7/23 16:16, songbird wrote:

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.

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

.


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 

Re: logging no longer standard?

[gene heskett]

On 8/7/23 13:23, Henning Follmann wrote:

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 +
Andy Smith  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.

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


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 

Re: logging no longer standard?

[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

Re: logging no longer standard?

[gene heskett]

On 8/7/23 12:19, songbird wrote:

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?


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

.


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 

Re: logging no longer standard?

[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 +
> > > > Andy Smith  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.

-H


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

Re: logging no longer standard?

[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

Re: logging no longer standard?

[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 +
Andy Smith  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)

Re: logging no longer standard?

[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 +
> > Andy Smith  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   | hfollm...@itcfollmann.com

Re: logging no longer standard?

[Max Nikulin]

On 06/08/2023 02:03, Joe wrote:

I use 'tail -f ' at least
once a week


journalctl -f

Re: logging no longer standard?

[Andy Smith]

Hello,

On Sat, Aug 05, 2023 at 08:03:27PM +0100, Joe wrote:
> On Sat, 5 Aug 2023 15:09:41 +
> Andy Smith  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:
. 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

Re: logging no longer standard?

[Greg Wooledge]

On Sat, Aug 05, 2023 at 08:03:27PM +0100, Joe wrote:
> On Sat, 5 Aug 2023 15:09:41 +
> Andy Smith  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.

Re: logging no longer standard?

[Joe]

On Sat, 5 Aug 2023 15:09:41 +
Andy Smith  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 ' 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

Re: logging no longer standard?

[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

Re: logging no longer standard?

[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

Re: logging no longer standard?

[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


signature.asc
Description: PGP signature

Re: logging no longer standard?

[err404]

On 8/5/23 14:56, Carl Fink wrote:

On 8/5/23 02:54, Michel Verdier wrote:

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

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



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)

Re: logging no longer standard?

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

Re: logging no longer standard?

[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

Re: logging no longer standard?

[Brian]

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

> On 8/5/23 02:54, Michel Verdier wrote:
> > 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
> 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.

Does this clarify?

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

Re: logging no longer standard?

[Carl Fink]

On 8/5/23 02:54, Michel Verdier wrote:

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

Re: logging no longer standard?

[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

Re: logging no longer standard?

[tomas]

On Fri, Aug 04, 2023 at 10:40:37PM -0400, 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.
> 
> 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.)

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


signature.asc
Description: PGP signature

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