Discussion:
[slrn] log of errors?
(too old to reply)
Lewis
2021-01-14 05:21:09 UTC
Permalink
When an article fails to post, the error on why it failed is displayed
by slrn for about 0.5 seconds, and then that error is erased and,
apparently vanishes from all knowledge.

Is this logged anywhere> Is there anyway to see what errors slrn has
encountered recently?
--
"In order to avoid being called a flirt, she always yielded easily."
Charles, Count Talleyrand
J.B. Nicholson
2021-01-16 01:43:49 UTC
Permalink
Post by Lewis
Is this logged anywhere> Is there anyway to see what errors slrn has
encountered recently?
By default slrn doesn't log errors so as to provide a recallable
log. I believe that slrn is designed chiefly for interactive use by a
user who is in front of the terminal with the running slrn process;
someone who would see the error message as it is displayed. slrn does
provide --debug, an option that could help you if you're trying to
diagnose a posting issue:

--debug FILE Write debugging information to FILE

Relatedly there is also an option to log the killed articles:

--kill-log FILE Keep a log of all killed articles in FILE

Where "FILE" in both options is the name or path of a writeable file
you wish to log to (probably wise to log each option to separate
files).

These descriptions came from "slrn --help" output.

slrn is free software -- users are free to run, inspect, share, and
modify the program under the terms of the GNU General Public License
version 2 or any later version (see the COPYRIGHT and COPYING files
for details). So if you want to you could write code to support a log
that works in the way you need it to work. You could also provide a
patch for John E. Davis (slrn's author) to incorporate in the next
version of slrn.
Lewis
2021-01-16 09:32:19 UTC
Permalink
Post by J.B. Nicholson
Post by Lewis
Is this logged anywhere> Is there anyway to see what errors slrn has
encountered recently?
By default slrn doesn't log errors so as to provide a recallable
log. I believe that slrn is designed chiefly for interactive use by a
user who is in front of the terminal with the running slrn process;
Yes, but the post errors are on screen, as I said, for only about half a
second. Not long enough for me to even see the number, much less read
the whole message, and then they are gone with no apparent cache or
recall.
Post by J.B. Nicholson
someone who would see the error message as it is displayed. slrn does
provide --debug, an option that could help you if you're trying to
These are almost always transient errors with the server or sometimes a
header has gotten mangled, but there's no real way to tell other than
to try to repost the article several times and see if you can catch
enough of the error.
--
no no no no no
no no no no no no no
no no no no no
J.B. Nicholson
2021-01-17 01:58:07 UTC
Permalink
Post by Lewis
These are almost always transient errors with the server or sometimes a
header has gotten mangled, but there's no real way to tell other than
to try to repost the article several times and see if you can catch
enough of the error.
What did you get when you tried running slrn with the --debug option?

It would be worth seeing if something indicating the error shows up in
the debug file. That feedback from the server is probably going to be
valuable in identifying what the server is complaining about.

If you want to see this debug log as it happens, consider using most
(John Davis' pager which also has 'tail -f' functionality to show
updates to a text file). Press 'f' in most to make most read the debug
file as the file is accumulating debug output and update the screen
accordingly, or cursor up/down to scroll through the debug file. That
would let you correlate the error no matter how quickly it flashes by
with text in the debug file.

You could post the debug file here along with a pointer to where the
error occurred; perhaps someone would help you pick out the relevant
text and identify what's going on.
Lewis
2021-01-17 02:18:12 UTC
Permalink
Post by J.B. Nicholson
Post by Lewis
These are almost always transient errors with the server or sometimes a
header has gotten mangled, but there's no real way to tell other than
to try to repost the article several times and see if you can catch
enough of the error.
What did you get when you tried running slrn with the --debug option?
I could run in debug for a week or more and not have any errors.

The point is not the errors, the point is that slrn displays them and
then immediately erases them before anyone wold have a chance to actually
look at and read the error.
Post by J.B. Nicholson
You could post the debug file here along with a pointer to where the
error occurred; perhaps someone would help you pick out the relevant
text and identify what's going on.
I get the sense that you do not use slrn and have no idea what the
problem is I am describing.
--
I have as much authority as the Pope, I just don't have as many
people who believe it.
Phil Boutros
2021-01-19 21:57:42 UTC
Permalink
Post by Lewis
I get the sense that you do not use slrn and have no idea what the
problem is I am describing.
User-Agent: slrn/1.0.3 (Linux)
I will say that if the --debug option isn't logging the error,
that does seem like a problem, though. Have you ever managed to
actually read what the error was?


Phil
--
AH#61 Wolf#14 BS#89 bus#1 CCB#1 SENS KOTC#4
***@philb.ca http://philb.ca
Lewis
2021-01-20 12:49:41 UTC
Permalink
Post by Phil Boutros
Post by Lewis
I get the sense that you do not use slrn and have no idea what the
problem is I am describing.
User-Agent: slrn/1.0.3 (Linux)
I will say that if the --debug option isn't logging the error,
that does seem like a problem, though. Have you ever managed to
actually read what the error was?
OK, let me try one more time.

On rare occasions there is a problem posting a message. slrn displays
the error at the bottom of the screen and then immediately erases the
display of the error.

I want to see that error.

I do not want to enable debug mode to then go digging through a log file
for the occasional and rare times this happens. I just want the error to
be displayed so that I can actually see it long enough to read it. Or to
display the errors that have occurred so I can see if the error is on
the server (and report it) or something I did (like accidentally deleting
the Newsgroups: header).

It seems kind of dumb to me to show and then erase an error message
before anyone could read it and have no way or retrieving it.
--
'You don't think you've had enough, do you?' he said. I KNOW WHEN
I'VE HAD ENOUGH. 'Everyone says that, though. I KNOW WHEN
EVERYONE'S HAD ENOUGH. --Moving Pictures
b***@ripco.com
2021-01-20 18:09:25 UTC
Permalink
Post by Lewis
It seems kind of dumb to me to show and then erase an error message
before anyone could read it and have no way or retrieving it.
It's possible even with the logs on full that the error message won't be
there.

There was some software I was screwing with a long time ago that did
something similar, printed an error message on occassion that disappeared in
a blink of an eye.

Turned out it was an error message from the nntp server that was just being
passed along. The actual error was never in the software logs, just the logs
on the nntp server.

The only thing I could figure at the time was the software didn't have the
specific error code in its built in table so it would just display it and
move along.

Seeing the logs on the nntp server when you are connected to it would be the
easiest way but I'd guess you aren't running your own server.

-bruce
***@ripco.com

Loading...