Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: rbowman <bowman@montana.com>
Newsgroups: comp.os.linux.misc
Subject: Re: Service startup errors
Date: 1 Jan 2026 02:31:54 GMT
Lines: 33
Message-ID: <mrm4kqFabpiU8@mid.individual.net>
References: <10if6e3$kag3$1@dont-email.me> <10igm6l$10hm7$2@dont-email.me> <10igpir$1086g$16@dont-email.me> <mr3ld3F6vguU6@mid.individual.net> <JmednRBE9pd2P9H0nZ2dnZfqn_idnZ2d@giganews.com> <20251226090654.00000d42@gmail.com> <mr830cFtgkdU2@mid.individual.net> <slrn10ktt6o.rut.lars@cleo.beagle-ears.com> <gpWcnan0rp9xxdL0nZ2dnZfqnPednZ2d@giganews.com> <slrn10l2ftn.20i38.lars@cleo.beagle-ears.com> <10is5pn$h12h$5@dont-email.me> <7cj82mxbaa.ln2@Telcontar.valinor> <10iscj0$jd63$2@dont-email.me> <slrn10l3i3g.22k9d.lars@cleo.beagle-ears.com> <cp-dnUmP6vBedsz0nZ2dnZfqnPWdnZ2d@giganews.com> <8dV4R.92219$4H_9.80362@fx37.iad> <mrjiktFqvk0U6@mid.individual.net> <10j2pfc$2eoas$1@dont-email.me> <wwv8qejht9a.fsf@LkoBDZeT.terraraq.uk> <10j435d$2s72e$9@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Trace: individual.net 5ygfMbVS/nhwGTndqQ/WxwU57C8nFgB3bCFQhOlaQrh50ysB5s
Cancel-Lock: sha1:GMJWnsJognz7cfouyPtS9SiyW5s= sha256:tOe9iGz4n7IJ+E2LY5h3ZfylZaViQD3OXqZ8px5VMq0=
User-Agent: Pan/0.162 (Pokrosvk)
Xref: csiph.com comp.os.linux.misc:80209

On Wed, 31 Dec 2025 21:04:45 -0000 (UTC), Lawrence D’Oliveiro wrote:

> On Wed, 31 Dec 2025 09:53:37 +0000, Richard Kettlewell wrote:
> 
>> ... perror writes to stderr, which is where the diagnostic ought to be.
> 
> Also, the argument to perror(3) should be an indication of *where* the
> error occurred. perror(3) itself will provide the rest.

The 'log_error()' function we used provided more information.'

[Thu Sep 05 15:10:51.255024 2024 (90.058331)] (pid = 1640) (fd = 73) 
requests.c:4569
verify_router_clnt: Netrouter returns error 4.

The PID served two functions. If the program dumped a core the convention 
was to name it core.pid like core.1640.  grep "pid = 1640" *.log allowed 
support to determine what had cored without poking around in the core with 
windbg.

In the log itself it was easy to find when the process started and 
stopped.  The file descriptor could be handy if the process was eating 
descriptors for some reason.  requests.c:4569 gave the source file and 
line  that was determined using __FILE__ and __LINE__.  The other number 
in parens was the seconds since the last log entry. Not always useful but 
it was easier than subtracting the timestamps.

This was a homegrown function but most of the decent log packages allow 
you to tailor the output to get more data than the errno. Unfortunately 
the netrouter return isn't a regular errno but a RPC status. We got better 
over the years but some of the logging was obscure.