* Re: Handling CTRL_LOGOFF_EVENT
@ 1999-02-19 10:36 Sergey Okhapkin
1999-02-19 12:52 ` Curtis Galloway
1999-02-28 23:02 ` Sergey Okhapkin
0 siblings, 2 replies; 16+ messages in thread
From: Sergey Okhapkin @ 1999-02-19 10:36 UTC (permalink / raw)
To: Curtis Galloway, cygwin
>I submitted a fix a while ago to the winsup module regarding bash hanging
when
>I rebooted my NT machine. The problem was that the cygwin signal handler
was
>returning TRUE after receiving a CTRL_CLOSE_EVENT or CTRL_SHUTDOWN_EVENT
window
>event, so Windows thought that cygwin programs refused to exit when you
were
It's very important to _ignore_ (return TRUE) CTRL_LOGOFF_EVENT to not
terminate cygwin apps running as services on user's logoff!
Sergey Okhapkin, http://www.lexa.ru/sos
Piscataway, NJ
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Handling CTRL_LOGOFF_EVENT
1999-02-19 10:36 Handling CTRL_LOGOFF_EVENT Sergey Okhapkin
@ 1999-02-19 12:52 ` Curtis Galloway
1999-02-28 23:02 ` Curtis Galloway
1999-02-28 23:02 ` Sergey Okhapkin
1 sibling, 1 reply; 16+ messages in thread
From: Curtis Galloway @ 1999-02-19 12:52 UTC (permalink / raw)
To: cygwin
Sergey Okhapkin wrote:
> It's very important to _ignore_ (return TRUE) CTRL_LOGOFF_EVENT to not
> terminate cygwin apps running as services on user's logoff!
From my reading of the Microsoft documentation, a service won't be terminated
no matter what it returns for a CTRL_LOGOFF_EVENT message. Does your
experience indicate otherwise?
--Curtis
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Handling CTRL_LOGOFF_EVENT
1999-02-19 10:36 Handling CTRL_LOGOFF_EVENT Sergey Okhapkin
1999-02-19 12:52 ` Curtis Galloway
@ 1999-02-28 23:02 ` Sergey Okhapkin
1 sibling, 0 replies; 16+ messages in thread
From: Sergey Okhapkin @ 1999-02-28 23:02 UTC (permalink / raw)
To: Curtis Galloway, cygwin
>I submitted a fix a while ago to the winsup module regarding bash hanging
when
>I rebooted my NT machine. The problem was that the cygwin signal handler
was
>returning TRUE after receiving a CTRL_CLOSE_EVENT or CTRL_SHUTDOWN_EVENT
window
>event, so Windows thought that cygwin programs refused to exit when you
were
It's very important to _ignore_ (return TRUE) CTRL_LOGOFF_EVENT to not
terminate cygwin apps running as services on user's logoff!
Sergey Okhapkin, http://www.lexa.ru/sos
Piscataway, NJ
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <38172EB6.6F7DC9BA@pdi.com>]
* Re: Handling CTRL_LOGOFF_EVENT
[not found] <38172EB6.6F7DC9BA@pdi.com>
@ 1999-10-28 7:12 ` Tom Rodman
1999-10-31 19:54 ` Tom Rodman
0 siblings, 1 reply; 16+ messages in thread
From: Tom Rodman @ 1999-10-28 7:12 UTC (permalink / raw)
To: Curtis Galloway, cygwin
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.Rodman@jci.com
>> home: rodmant@sol.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@sourceware.cygnus.com
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: Handling CTRL_LOGOFF_EVENT
1999-10-28 7:12 ` Tom Rodman
@ 1999-10-31 19:54 ` Tom Rodman
0 siblings, 0 replies; 16+ messages in thread
From: Tom Rodman @ 1999-10-31 19:54 UTC (permalink / raw)
To: Curtis Galloway, cygwin
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.Rodman@jci.com
>> home: rodmant@sol.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@sourceware.cygnus.com
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Handling CTRL_LOGOFF_EVENT
@ 1999-02-19 13:18 Sergey Okhapkin
1999-02-19 15:47 ` Curtis Galloway
1999-02-28 23:02 ` Sergey Okhapkin
0 siblings, 2 replies; 16+ messages in thread
From: Sergey Okhapkin @ 1999-02-19 13:18 UTC (permalink / raw)
To: Curtis Galloway, cygwin
From my reading of the Microsoft documentation, a service won't be
terminated
>no matter what it returns for a CTRL_LOGOFF_EVENT message. Does your
>experience indicate otherwise?
>
CTRL_LOGOFF_EVENT is sent to every running application including services.
Sergey Okhapkin, http://www.lexa.ru/sos
Piscataway, NJ
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Handling CTRL_LOGOFF_EVENT
1999-02-19 13:18 Sergey Okhapkin
@ 1999-02-19 15:47 ` Curtis Galloway
[not found] ` < 36CDF573.361DC410@pdi.com >
` (2 more replies)
1999-02-28 23:02 ` Sergey Okhapkin
1 sibling, 3 replies; 16+ messages in thread
From: Curtis Galloway @ 1999-02-19 15:47 UTC (permalink / raw)
To: Sergey Okhapkin; +Cc: cygwin
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@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 16+ messages in thread[parent not found: < 36CDF573.361DC410@pdi.com >]
* Re: Handling CTRL_LOGOFF_EVENT
[not found] ` < 36CDF573.361DC410@pdi.com >
@ 1999-02-19 17:24 ` Christopher Faylor
1999-02-28 23:02 ` Christopher Faylor
0 siblings, 1 reply; 16+ messages in thread
From: Christopher Faylor @ 1999-02-19 17:24 UTC (permalink / raw)
To: Curtis Galloway, Sergey Okhapkin; +Cc: cygwin
On Fri, Feb 19, 1999 at 03:36:19PM -0800, 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.)
If you guys can come to a consensus on this, I'll be happy to put whatever
fix you think fixes the problem into cygwin.
-chris
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: Handling CTRL_LOGOFF_EVENT
1999-02-19 17:24 ` Christopher Faylor
@ 1999-02-28 23:02 ` Christopher Faylor
0 siblings, 0 replies; 16+ messages in thread
From: Christopher Faylor @ 1999-02-28 23:02 UTC (permalink / raw)
To: Curtis Galloway, Sergey Okhapkin; +Cc: cygwin
On Fri, Feb 19, 1999 at 03:36:19PM -0800, 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.)
If you guys can come to a consensus on this, I'll be happy to put whatever
fix you think fixes the problem into cygwin.
-chris
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Handling CTRL_LOGOFF_EVENT
1999-02-19 15:47 ` Curtis Galloway
[not found] ` < 36CDF573.361DC410@pdi.com >
@ 1999-02-28 23:02 ` Curtis Galloway
1999-10-27 5:42 ` Tom Rodman
2 siblings, 0 replies; 16+ messages in thread
From: Curtis Galloway @ 1999-02-28 23:02 UTC (permalink / raw)
To: Sergey Okhapkin; +Cc: cygwin
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@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: Handling CTRL_LOGOFF_EVENT
1999-02-19 15:47 ` Curtis Galloway
[not found] ` < 36CDF573.361DC410@pdi.com >
1999-02-28 23:02 ` Curtis Galloway
@ 1999-10-27 5:42 ` Tom Rodman
1999-10-31 19:54 ` Tom Rodman
2 siblings, 1 reply; 16+ messages in thread
From: Tom Rodman @ 1999-10-27 5:42 UTC (permalink / raw)
To: Curtis Galloway; +Cc: Sergey Okhapkin
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.Rodman@jci.com
home: rodmant@sol.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@sourceware.cygnus.com
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: Handling CTRL_LOGOFF_EVENT
1999-10-27 5:42 ` Tom Rodman
@ 1999-10-31 19:54 ` Tom Rodman
0 siblings, 0 replies; 16+ messages in thread
From: Tom Rodman @ 1999-10-31 19:54 UTC (permalink / raw)
To: Curtis Galloway; +Cc: Sergey Okhapkin
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.Rodman@jci.com
home: rodmant@sol.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@sourceware.cygnus.com
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Handling CTRL_LOGOFF_EVENT
1999-02-19 13:18 Sergey Okhapkin
1999-02-19 15:47 ` Curtis Galloway
@ 1999-02-28 23:02 ` Sergey Okhapkin
1 sibling, 0 replies; 16+ messages in thread
From: Sergey Okhapkin @ 1999-02-28 23:02 UTC (permalink / raw)
To: Curtis Galloway, cygwin
From my reading of the Microsoft documentation, a service won't be
terminated
>no matter what it returns for a CTRL_LOGOFF_EVENT message. Does your
>experience indicate otherwise?
>
CTRL_LOGOFF_EVENT is sent to every running application including services.
Sergey Okhapkin, http://www.lexa.ru/sos
Piscataway, NJ
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* Handling CTRL_LOGOFF_EVENT
@ 1999-02-19 9:27 Curtis Galloway
1999-02-28 23:02 ` Curtis Galloway
0 siblings, 1 reply; 16+ messages in thread
From: Curtis Galloway @ 1999-02-19 9:27 UTC (permalink / raw)
To: cygwin
I submitted a fix a while ago to the winsup module regarding bash hanging when
I rebooted my NT machine. The problem was that the cygwin signal handler was
returning TRUE after receiving a CTRL_CLOSE_EVENT or CTRL_SHUTDOWN_EVENT window
event, so Windows thought that cygwin programs refused to exit when you were
shutting down the system. This resulted in Windows popping up a dialog box for
every open bash window asking if you wanted to kill the program.
That particular problem was fixed, but the problem still occurs if you log out
rather than shutting down the machine. I have enclosed a patch below, which I
have been using for some time with no problems.
I haven't tested with programs that act as NT services, though, and I'm unsure
what the consequences of this change would be to such a program. Anyone
writing NT services out there?
--Curtis
*** exceptions.cc.00 Fri Dec 04 04:35:03 1998
--- exceptions.cc Wed Jan 27 15:45:54 1999
***************
*** 534,540 ****
BOOL ret;
if (type == CTRL_LOGOFF_EVENT)
! return 1;
if ((type == CTRL_CLOSE_EVENT) || (type == CTRL_SHUTDOWN_EVENT))
/* Return FALSE to prevent an "End task" dialog box from appearing
--- 534,540 ----
BOOL ret;
if (type == CTRL_LOGOFF_EVENT)
! return FALSE;
if ((type == CTRL_CLOSE_EVENT) || (type == CTRL_SHUTDOWN_EVENT))
/* Return FALSE to prevent an "End task" dialog box from appearing
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 16+ messages in thread* Handling CTRL_LOGOFF_EVENT
1999-02-19 9:27 Curtis Galloway
@ 1999-02-28 23:02 ` Curtis Galloway
0 siblings, 0 replies; 16+ messages in thread
From: Curtis Galloway @ 1999-02-28 23:02 UTC (permalink / raw)
To: cygwin
I submitted a fix a while ago to the winsup module regarding bash hanging when
I rebooted my NT machine. The problem was that the cygwin signal handler was
returning TRUE after receiving a CTRL_CLOSE_EVENT or CTRL_SHUTDOWN_EVENT window
event, so Windows thought that cygwin programs refused to exit when you were
shutting down the system. This resulted in Windows popping up a dialog box for
every open bash window asking if you wanted to kill the program.
That particular problem was fixed, but the problem still occurs if you log out
rather than shutting down the machine. I have enclosed a patch below, which I
have been using for some time with no problems.
I haven't tested with programs that act as NT services, though, and I'm unsure
what the consequences of this change would be to such a program. Anyone
writing NT services out there?
--Curtis
*** exceptions.cc.00 Fri Dec 04 04:35:03 1998
--- exceptions.cc Wed Jan 27 15:45:54 1999
***************
*** 534,540 ****
BOOL ret;
if (type == CTRL_LOGOFF_EVENT)
! return 1;
if ((type == CTRL_CLOSE_EVENT) || (type == CTRL_SHUTDOWN_EVENT))
/* Return FALSE to prevent an "End task" dialog box from appearing
--- 534,540 ----
BOOL ret;
if (type == CTRL_LOGOFF_EVENT)
! return FALSE;
if ((type == CTRL_CLOSE_EVENT) || (type == CTRL_SHUTDOWN_EVENT))
/* Return FALSE to prevent an "End task" dialog box from appearing
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~1999-10-31 19:54 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-02-19 10:36 Handling CTRL_LOGOFF_EVENT Sergey Okhapkin
1999-02-19 12:52 ` Curtis Galloway
1999-02-28 23:02 ` Curtis Galloway
1999-02-28 23:02 ` Sergey Okhapkin
[not found] <38172EB6.6F7DC9BA@pdi.com>
1999-10-28 7:12 ` Tom Rodman
1999-10-31 19:54 ` Tom Rodman
-- strict thread matches above, loose matches on Subject: below --
1999-02-19 13:18 Sergey Okhapkin
1999-02-19 15:47 ` Curtis Galloway
[not found] ` < 36CDF573.361DC410@pdi.com >
1999-02-19 17:24 ` Christopher Faylor
1999-02-28 23:02 ` Christopher Faylor
1999-02-28 23:02 ` Curtis Galloway
1999-10-27 5:42 ` Tom Rodman
1999-10-31 19:54 ` Tom Rodman
1999-02-28 23:02 ` Sergey Okhapkin
1999-02-19 9:27 Curtis Galloway
1999-02-28 23:02 ` Curtis Galloway
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).