tasking programs built with GNAT insensitive to SIGTERM

tasking programs built with GNAT insensitive to SIGTERM

[Oliver Kellogg]

Hi,

Under Linux, how come tasking programs built with GNAT
(3.2, but other versions as well) don't react to 
"kill -TERM" ?

Is there a trick to make them killable?

See also http://gcc.gnu.org/cgi-bin/gnatsweb.pl,
bug number 9480.

Thanks,

Oliver

-- okellogg at freenet dot de

Re: tasking programs built with GNAT insensitive to SIGTERM

[David C. Hoos]

----- Original Message ----- 
From: "Oliver Kellogg" <okellogg@freenet.de>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: Wednesday, January 29, 2003 9:04 AM
Subject: tasking programs built with GNAT insensitive to SIGTERM


> Hi,
> 
> Under Linux, how come tasking programs built with GNAT
> (3.2, but other versions as well) don't react to 
> "kill -TERM" ?

Have you tried kill -KILL?  Is it possible that the tasking runtime is
setting the program up to ignore SIGTERM?

Another possibility is that because GNAT tasking is using Linux
threads, not all threads are receiving the signal. You can insure
that all signals in a process group receive a signal by specifying
the negative of the process group id in place of the process id
in the kill command.

David
> 
> Is there a trick to make them killable?
> 
> See also http://gcc.gnu.org/cgi-bin/gnatsweb.pl,
> bug number 9480.
> 
> Thanks,
> 
> Oliver
> 
> -- okellogg at freenet dot de
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
> 

Re: tasking programs built with GNAT insensitive to SIGTERM

[James S. Rogers]

"David C. Hoos" <david.c.hoos.sr@ada95.com> wrote in message
news:mailman.12.1043862309.30820.comp.lang.ada@ada.eu.org...
>
> ----- Original Message -----
> From: "Oliver Kellogg" <okellogg@freenet.de>
> Newsgroups: comp.lang.ada
> To: <comp.lang.ada@ada.eu.org>
> Sent: Wednesday, January 29, 2003 9:04 AM
> Subject: tasking programs built with GNAT insensitive to SIGTERM
>
>
> > Hi,
> >
> > Under Linux, how come tasking programs built with GNAT
> > (3.2, but other versions as well) don't react to
> > "kill -TERM" ?
>
> Have you tried kill -KILL?  Is it possible that the tasking runtime is
> setting the program up to ignore SIGTERM?
>
> Another possibility is that because GNAT tasking is using Linux
> threads, not all threads are receiving the signal. You can insure
> that all signals in a process group receive a signal by specifying
> the negative of the process group id in place of the process id
> in the kill command.
>
> David
> >
> > Is there a trick to make them killable?
> >
> > See also http://gcc.gnu.org/cgi-bin/gnatsweb.pl,
> > bug number 9480.
> >
> > Thanks,
> >
> > Oliver

A discussion of signals and Linux Threads on comp.programming.threads
indicates that Linux Threads are broken regarding handling signals.
This appears to have revealed the same weakness.

Jim Rogers

Re: tasking programs built with GNAT insensitive to SIGTERM

[Mark Johnson]

Oliver Kellogg wrote:
> 
> Hi,
> 
> Under Linux, how come tasking programs built with GNAT
> (3.2, but other versions as well) don't react to
> "kill -TERM" ?
> 
> Is there a trick to make them killable?
> 
> See also http://gcc.gnu.org/cgi-bin/gnatsweb.pl,
> bug number 9480.
> 
Hmm. Very odd behavior. You can probably get what you want by using
  pragma Interrupt_State (SIGTERM, System);

Which forces SIGTERM to be handled as a "system" interrupt. See the GNAT
Reference Manual for more details. I ran a test program and it appears
to do what you want it to.

It is odd enough - I may forward it to ACT to see what they say about
it. Also note - you DO have to hit one of the threads that has that
signal enabled to make it terminate the program. The main program is OK
(usually the process with the lowest PID), but the thread manager
(usually main PID +1) has the signal masked.

  --Mark

Re: tasking programs built with GNAT insensitive to SIGTERM

[Craig Carey]

On Wed, 29 Jan 2003 15:54:38 -0600, Mark Johnson
<mark_h_johnson@raytheon.com> wrote:

>Oliver Kellogg wrote:
...
>> Under Linux, how come tasking programs built with GNAT
>> (3.2, but other versions as well) don't react to
>> "kill -TERM" ?
>> 
>> Is there a trick to make them killable?
>> 

For GNAT 3.15p in Linux with native threads, attaching a signal handler
for SIGTERM (see below) fixes the problem so that the thread can be
terminated with "kill -s TERM <pid>".

Unfortunately 3 new threads that ignored SIGTERM are added if the
method is used (but it is better, since all 4 die if the right thread
is TERM-ed). I sent in a bug report saying that 4 is too many.



>> See also http://gcc.gnu.org/cgi-bin/gnatsweb.pl
>> bug number 9480.
>> 
>Hmm. Very odd behavior. You can probably get what you want by using
>  pragma Interrupt_State (SIGTERM, System);
>

What is the compiler that implements a pragma 'Interrupt_State' ?.
(The GNAT compiler I tried didn't understand that pragma).

>Which forces SIGTERM to be handled as a "system" interrupt. See the GNAT

The simple example of problem 9480 did not try to handle SIGTERM signals.


>Reference Manual for more details. I ran a test program and it appears
>to do what you want it to.
>
>It is odd enough - I may forward it to ACT to see what they say about
>it.

Any information on when GNAT will run as well in Linux as it does in
Windows 200 ?: one Ctrl-C (a plain Windows signal) and the program is
100% removed from memory.

> Also note - you DO have to hit one of the threads that has that
>signal enabled to make it terminate the program. The main program is OK

Isn't that a compiler vendor or OS bug?. SIGKILL terminates all of the
4 threads no matter which of that signal is sent to, so why have only
one of the four take all four down when SIGTERM is the signal ?.


>(usually the process with the lowest PID), but the thread manager
>(usually main PID +1) has the signal masked.


Here is solution but it is not as good as would be hoped for.

(1) The 1.3 second delay statement can be replaced with a 'Timed Entry
 Call':

    AARM 9.7.2 Timed Entry Calls:
    http://www.adaic.org/standards/95aarm/html/AA-9-7-2.html

      --  A protected object stops blocking when SIGTERM was receieved
   select
      Signals.Shutdown;
      goto ... --  exit program
   or
      delay 1.3;
   end select;
   ...
  
   protected Signals is
      procedure SIGTERM_Handler;   --  unblocks the Shutdown barrier
      pragma Interrupt_Handler (SIGTERM_Handler);
      pragma Attach_Handler (SIGTERM_Handler,
                  Ada.Interrupts.Names.SIGTERM);


If the delay was much bigger than 1.3 secs, and also C's exit() was used
to close the program, then the program would readily be stuck in memory
as a zombie, at least in Linux and Linux emulators.
If exit() is not used then the Timed Entry Call is more likely to be
used.




G. A. Craig Carey
http://www.ijs.co.nz/ada_95.htm

Re: tasking programs built with GNAT insensitive to SIGTERM

[Mark Johnson]

Craig Carey wrote:
> 
> On Wed, 29 Jan 2003 15:54:38 -0600, Mark Johnson
> <mark_h_johnson@raytheon.com> wrote:
> 
> >Oliver Kellogg wrote:
> ...
> >> See also http://gcc.gnu.org/cgi-bin/gnatsweb.pl
> >> bug number 9480.
> >>
> >Hmm. Very odd behavior. You can probably get what you want by using
> >  pragma Interrupt_State (SIGTERM, System);
> >
> 
> What is the compiler that implements a pragma 'Interrupt_State' ?.
> (The GNAT compiler I tried didn't understand that pragma).
> 
I was using the default on the machine in my office which happened to be
3.16w. This is a new version of the compiler, run time, etc. Hmm.
Switching back to a 3.14 or 3.15 version calls that "unrecognized" for
me as well - apparently this is something ACT just added. In looking at
the run time changes in 3.16w, there are some new routines defined to
"make this so", but the comments don't mention the rationale. The
features file lists briefly "Better control of signal / interrupt
handling" but does not go into much detail either.

> >Which forces SIGTERM to be handled as a "system" interrupt. See the GNAT
> 
> The simple example of problem 9480 did not try to handle SIGTERM signals.
> 
I know that. I made that point when I sent this example to ACT. I am
actually more concerned that SIGHUP is ignored in the same way - that
can cause a remote job to stay running long after its terminal
connection is lost. In the replies I have to date from Robert, he does
not consider the change in behavior (from single task to multi tasking)
to be a "bug". I strongly disagree. As a paying customer, I may have
some leverage on this particular issue.

> >Reference Manual for more details. I ran a test program and it appears
> >to do what you want it to.
> >
> >It is odd enough - I may forward it to ACT to see what they say about
> >it.
> 
> Any information on when GNAT will run as well in Linux as it does in
> Windows 200 ?: one Ctrl-C (a plain Windows signal) and the program is
> 100% removed from memory.
> 
Delivering SIGINT (or hitting Ctrl-C) works just fine for me. From man 7
signal
  SIGINT  2   A   Interrupt from keyboard
Your sample program gets cleaned up just fine with Ctrl-C (even when
built with 3.14). Are you seeing some different behavior?

Note that SIGTERM and SIGHUP have different causes than SIGINT. From the
same man page, all three have the same default action (terminate the
process). Perhaps you have these mixed up?

> > Also note - you DO have to hit one of the threads that has that
> >signal enabled to make it terminate the program. The main program is OK
> 
> Isn't that a compiler vendor or OS bug?. SIGKILL terminates all of the
> 4 threads no matter which of that signal is sent to, so why have only
> one of the four take all four down when SIGTERM is the signal ?.
> 
Note that SIGKILL cannot be caught nor ignored. The process manager
notices the killed process and takes down the whole set. The behavior
you are seeing with the other signals is they can be ignored (or perhaps
being caught and not acted on). I am not quite sure *why* the GNAT run
time does this and I did not find the code doing that in a quick review
of the source code in
/usr/gnat/lib/gcc-lib/i686-pc-linux-gnu/2.8.1/adainclude. There is some
rationale to what is done in the runtime in s-intman.adb (same
directory) and explained more clearly in "A Detailed Description of the
GNU Ada Run Time" by Javier Miranda [announced a few months ago on CLA].
But even reading through all this, I don't see the rationale for
ignoring the non-reserved signals.

Also - it is a "well known bug" that Linux threads do not handle signals
in a Posix compliant manner. Check comp.programming.threads and see a
number of discussions about that particular issue. It seems to come up
as a topic about once a quarter or so. As I see it, there is both a OS
and run time bug here.

If you handle the signal (as in your sample code), the GNAT run time on
Linux will ignore that signal on all threads EXCEPT the one handling the
signal. Our particular solution for this was to "killpg" the process
group so the signal gets delivered to all the threads (and ignored by
all but one).

  --Mark