From: bowman@montana.com   
      
   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.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)