[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: logging no longer standard?



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

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 <http://geneslinuxbox.net:6309/>


Reply to: