XPost: uk.comp.os.linux   
   From: usenet.16@scottsonline.org.uk.invalid   
      
   On 11/09/2025 08:49, Richard Kettlewell wrote:   
   > Mike Scott writes:   
   >> On 10/09/2025 09:42, Dan Purgert wrote:   
   >>> On 2025-09-10, Mike Scott wrote:   
   >>>> On 04/09/2025 08:26, Richard Kettlewell wrote:   
   >>>>> Mike Scott>>> ottsonline.org.uk.invalid> writes:   
   >>>>>> I've been using a program 'daemon' on freebsd   
   >>>>>> (eg   
   >>>>>> man.freebsd.org/cgi/man.cgi?query=daemon&sektion=8&manpat   
   =FreeBSD+14.3-RELEASE+and+Ports)   
   >>>>>>   
   >>>>>> which will run arbitrary programs as daemons, handling all the   
   >>>>>> necessary "house-keeping" for them.   
   >>>>>>   
   >>>>>> I can't find a ready-to-roll linux version - is there one please?   
   >>>>> If you want an (almost) identical interface then in Debian (and   
   >>>>> presumably therefore also Ubuntu), there’s a command of the same name   
   >>>>> and similar behavior:   
   >>>>>   
   >>>>> https://manpages.debian.org/trixie/daemon/daemon.1.en.html   
   >>>>   
   >>>> Sorry, back again.   
   >>>>   
   >>>> I've been playing with this and there seems to be an important feature   
   >>>> missing on linux that's in the BSD version: how to do logfile rotation?   
   >>>> [...]   
   >>>> Have I missed something?   
   >>> logrotate(8) ?   
   >>   
   >> Thanks for the reply, but no. That assumes the existence of the   
   >> mechanism missing AFAICS from this daemon.   
   >>   
   >> And to answer ldo, this is for a web daemon that writes its own   
   >> private log file that needs archival copies kept; syslog is not   
   >> appropriate. I've been doing that using mv and sending the BSD daemon   
   >> a sighup; migration is being something of a chore.   
   >>   
   >> Looks like I'll have to see about patching the daemon source code.   
   >   
   > I’m not quite clear on the requirement here. I think what you mean is:   
   >   
   > * The daemon executable logs to stdout and/or stderr   
   > * You want these logs saved to a file   
   > * You want this file rotated (in the normal way for a logfile)   
   > * You want to keep the data essentially indefinitely, or at least, for   
   > longer than other syslog outputs.   
   >   
   > I can see several options.   
   >   
   > 1) Change the daemon to log to the target file instead of stdout/stderr,   
   > and either arrange for it to close and re-open the logfile when it   
   > recieves SIGHUP, or just do the log rotate itself (which avoids   
   > dealing with signal handlers).   
   >   
   > 2) Add a second program that reads from stdin and writes to the target   
   > logfile, doing the log rotation itself. The daemon command line would   
   > be a pipeline, e.g. daemon sh -c "executable 2>&1 | loghandler".   
   >   
   > 3) Log to syslog, either directly or via the daemon wrapper. syslog   
   > daemons (e.g. rsyslogd) can select a specific program’s logs to an   
   > individual file, and you can control the log rotation policy for that   
   > file individually. The syslog daemon takes care of the close/re-open   
   > dance.   
   >   
      
   The problem is fixed to my satisfaction, but to answer your query.   
      
   The target program runs unattended for extended periods. It writes a lot   
   of data to stdout and stderr. It is not of itself a daemon in the linux   
   sense, just a large chunk of perl code that normally runs at a terminal.   
   To make it a self-contained linux daemon would be a pain, and pointless   
   duplication of code. At user-determined intervals, I need output to be   
   directed to a fresh file.   
      
   On freebsd, I've been using a program called 'daemon'. This runs the   
   target program as a child process, intercepting its stdout and stderr   
   and writing their data to a suitable file; it also does the necessary   
   detaching and other housekeeping operations on its behalf. Importantly,   
   'daemon' responds to a suitable signal by closing and reopening its   
   output. This provides a way of chopping up the target program's output   
   streams into files for archiving and further processing without stopping it.   
      
   The linux program of the same name does much the same - but lacks the   
   ability to close and reopen its output files. 'logrotate' can sort-of   
   work around this with a (small) risk of data loss for programs like   
   mine, that cannot handle rotation hygienically.   
      
   I've now modified the linux 'daemon' program to respond as the freebsd   
   one, and it can now close and reopen its output file(s) without risk of   
   data loss. So archiving now becomes a simple matter of "mv log.txt   
   log.old; kill -usr2 " which results in log.old with the data   
   to date, and a fresh log.txt being opened.   
      
   I've emailed the author to see if he's interested in rolling the   
   modification into the next release.   
      
   And yes, I suppose your suggestion #2 would have worked. But involving a   
   3rd program is messy, and I'd still be having cut code to tell it to do   
   the log rotation on request. Better to put that where it really belongs,   
   I think. But thanks for the idea.   
      
      
      
   --   
   Mike Scott   
   Harlow, England   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   
|