[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: loginfo log messages

From: Dan Peterson
Subject: Re: loginfo log messages
Date: Tue, 11 Mar 2003 20:58:05 -0800 (Pacific Standard Time)

On Tue, 11 Mar 2003 address@hidden wrote:

> On Tue, 11 Mar 2003 address@hidden wrote:
>> What is the exact content of your $CVSROOT/CVSROOT/loginfo file?
> DEFAULT (/home/cvsuser/cvs-scripts/cvs-mail-checkin-notifications %{sVv} >> 
> /home/cvsuser/cvslogs/commit-mailer.log 2>&1)&

I believe the reason you're not seeing anything on STDIN is because you're
putting the process in the background.  The data the CVS server sends to
STDIN is going to the parent of the background process, not the background
process itself.

You can solve this in a few different ways:

1. Don't put the process in the background:

  DEFAULT myscript %{sVv} >> mylog 2>&1

If the script is quick or you don't care that the commit will wait until
the script is done, then you don't need to put it in the background.

One note of caution in this case, don't try to issue any CVS commands
within the script that act on the same module (eg. cvs rlog).  If you do,
you'll get a "waiting on lock" message, because the "commit" is waiting
until the loginfo script returns before unlocking the module.

2. Force the parent of your background process to send STDIN to the
background child process:

  DEFAULT cat | (myscript %{sVv} >> mylog 2>&1) &

3. Run the script in the foreground... just log enough to read in STDIN,
then have it put itself into the background:

  DEFAULT myscript %{sVv} >> mylog 2>&1

And the script might look something like:


  # Read STDIN before going into the background.
  my $stdin = do { local $/; <STDIN> };

  # Fork a child process and exit from the parent.
  fork() and exit(0);

  # Let the child process sleep for a bit if you want.

  # Do stuff that takes a long time.

  # Do something with the original stuff from STDIN.


PS. I've seen some cases where the commit hung around until the background
process was complete and I'm not 100% sure why.  One thing I've done to
get around it is to fork, then in the child process, chdir('/'), close
STDIN, STDOUT and STDERR and POSIX::setsid().  This will make sure the
background process is completely disassociated with the parent - different
process group and parent is now init (eg. 1).

Of course if you close STDOUT, then you'll need to print to something
other than STDOUT or you'll need to dup STDOUT before closing it.

PPS. You should also be very cautious using the %{sVv} string if any of
your file/directory names contain spaces.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]