[slrn] log of errors?

[Lewis]

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]

Lewis <g.k...@kreme.dont-email.me> wrote:
> 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]

In message <slrns04h6...@forestfield.org> J.B. Nicholson <j...@forestfield.org> wrote:
> Lewis <g.k...@kreme.dont-email.me> wrote:
>> 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.

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

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]

Lewis <g.k...@kreme.dont-email.me> wrote:
> 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]

In message <slrns076d...@forestfield.org> J.B. Nicholson <j...@forestfield.org> wrote:
> Lewis <g.k...@kreme.dont-email.me> wrote:
>> 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.

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

Lewis <g.k...@kreme.dont-email.me> wrote:
>
> I get the sense that you do not use slrn and have no idea what the
> problem is I am describing.

I get the sense your first assertion is incorrect:

> 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
ph...@philb.ca http://philb.ca

[Lewis]

In message <slrns0elel...@ah61.is-a-geek.com> Phil Boutros <ph...@philb.ca> wrote:
> Lewis <g.k...@kreme.dont-email.me> wrote:
>>
>> I get the sense that you do not use slrn and have no idea what the
>> problem is I am describing.

> I get the sense your first assertion is incorrect:

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

Lewis <g.k...@kreme.dont-email.me> wrote:

> 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
b...@ripco.com