delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/1999/10/28/10:13:41

Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT sourceware DOT cygnus DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
Message-Id: <199910281258.HAA03921@tigris.pounder.sol.net>
To: Curtis Galloway <curtis AT pdi DOT com>, cygwin AT sourceware DOT cygnus DOT com
Reply-to: Tom Rodman <rodmant AT sol DOT net>
From: Tom Rodman <rodmant AT sol DOT net>
X-note: Return-Receipt-To: rodmant AT sol DOT net
Subject: Re: Handling CTRL_LOGOFF_EVENT
In-reply-to: Your message of "Wed, 27 Oct 1999 09:56:22 PDT."
<38172EB6 DOT 6F7DC9BA AT pdi DOT com>
Date: Thu, 28 Oct 1999 07:58:16 -0500

Curtis:

We tried trapping all signals in our script as shown:

     >                  /tmp
     > CMKE777 adm > trap   
     trap -- 'STATUS=$?; echo "TRAP(0/$STATUS)"' EXIT
     trap -- 'STATUS=$?; echo "TRAP(1/$STATUS)"' SIGINT
     trap -- 'STATUS=$?; echo "TRAP(2/$STATUS)"' SIGKILL
     trap -- 'STATUS=$?; echo "TRAP(3/$STATUS)"' SIGPIPE
     trap -- 'STATUS=$?; echo "TRAP(4/$STATUS)"' SIGFPE 
     trap -- 'STATUS=$?; echo "TRAP(5/$STATUS)"' SIGHUP
     trap -- 'STATUS=$?; echo "TRAP(6/$STATUS)"' SIGTERM
     trap -- 'STATUS=$?; echo "TRAP(7/$STATUS)"' SIGSEGV
     trap -- 'STATUS=$?; echo "TRAP(8/$STATUS)"' SIGTSTP
     trap -- 'STATUS=$?; echo "TRAP(9/$STATUS)"' SIGQUIT
     trap -- 'STATUS=$?; echo "TRAP(10/$STATUS)"' SIGTRAP
     trap -- 'STATUS=$?; echo "TRAP(11/$STATUS)"' SIGILL 
     trap -- 'STATUS=$?; echo "TRAP(12/$STATUS)"' SIGEMT
     trap -- 'STATUS=$?; echo "TRAP(13/$STATUS)"' SIGALRM
     trap -- 'STATUS=$?; echo "TRAP(14/$STATUS)"' SIGBUS 
     trap -- 'STATUS=$?; echo "TRAP(15/$STATUS)"' SIGLOST
     trap -- 'STATUS=$?; echo "TRAP(16/$STATUS)"' SIGSTOP
     trap -- 'STATUS=$?; echo "TRAP(17/$STATUS)"' SIGABRT
     trap -- 'STATUS=$?; echo"TRAP(18/$STATUS)"' SIGUSR1
     trap -- 'STATUS=$?; echo "TRAP(19/$STATUS)"' SIGUSR2
     trap -- 'STATUS=$?; echo "TRAP(20/$STATUS)"' SIGCHLD
     trap -- 'STATUS=$?; echo "TRAP(21/$STATUS)"' SIGTTOU
     trap -- 'STATUS=$?; echo "TRAP(22/$STATUS)"' SIGTTIN
     trap -- 'STATUS=$?; echo "TRAP(23/$STATUS)"' SIGCONT

The script we launch sends STDOUT/STDERR to a log file.

None of the above traps fired off, when rexec ended the session,
but the bash script launched by rexec and placed in the background
silently fails/stops ( i.e. the logging stops ).

I've also tried placing the script into the background using
"nohup".  In that case rexec waits until the background script
is done to terminate, so nohup is not a soln.  Also can't
find the log file created by nohup.  I'll try the nohup approach
again to be certain I was not being fooled ;->

-Tom

On Wed 10/27/99 9:56 PDT Curtis Galloway wrote:
>This doesn't sound like the CTRL_LOGOFF_EVENT problem, which happens when you
>log out of the machine.  More likely it's a signal handling problem.
>
>--Curtis
>
>Tom Rodman wrote:
>> 
>> We're end-users of bash here at Johnson Controls. We are using our
>> own rexec command to start a cmd file on a remote box; the cmd
>> file launches our bash scripts just fine. We'd like to be able to
>> have these bash scripts run as batch jobs in the background so
>> rexec can return quickly on the client machine. When we try backgrounding
>> the bash script,
>> it silently dies (traps don't catch anything) when
>> the rexec terminates. Is this due to the CTRL_LOGOFF_EVENT issue?
>> Is there a workaround for us that would allow our bash scripts to
>> be launched remotely with the permissions of the person requesting
>> the job without keeping a network connection open for the duration
>> of the job?
>> 
>>                 thanks,
>>                        Tom Rodman
>>                        (414) 274-5041/fax:4400
>> 
>>                        Johnson Controls/ Milwaukee WI
>>                        work: Tom DOT Rodman AT jci DOT com
>>                        home: rodmant AT sol DOT net
>> 
>> On Fri 2/19/99 15:36 PST Curtis Galloway wrote:
>> >Sergey Okhapkin wrote:
>> >> CTRL_LOGOFF_EVENT is sent to every running application including services.
>> >
>> >Yes, but does it terminate your process if you return FALSE in your handler?  I
>> >don't think so.
>> >
>> >I did a quick test using my modified cygwin1.dll.  I created a simple program
>> >that does nothing but write log messages to a file, and installed it as a
>> >service using the NT Resource Kit's SRVANY.EXE tool.  Even though my modified
>> >event handler returns FALSE, my test service survived through logging out and
>> >back in again.
>> >
>> >Perhaps my test was invalid.  If so, I'd be happy to hear about it.  (I still
>> >don't think the signal handling in exceptions.cc is quite right; it appears to
>> >not give programs a chance to handle the CTRL_CLOSE_EVENT or
>> >CTRL_SHUTDOWN_EVENT before Windows kills the process off.)
>> >
>> >--Curtis
>> >
>> >--
>> >Want to unsubscribe from this list?
>> >Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019