On Sat 10/Jan/2015 00:08:04 +0100 Sam Varshavchik wrote: 
> Alessandro Vesely writes:
> 
>>> Currently, the shutdown code just gives up, after a timeout, in this 
>>> manner. I
>>> do agree that an attempt should be made to kill all processes, after a
>>> reasonable timeout, so it's something that I need to look at.
>>
>> To kill by pid is going to be difficult for forked filters.  I issue a call
>> kill(0, SIGTERM) when the pipe is closed, but I had previously called 
>> setsid().
>> SIGTERM (15) should suffice to quickly exit; SIGKILL (9) is what I'd call
>> "overkill".  It seems several users issue `killall -9 ...`.  It shouldn't be
>> needed, and I'd expect some kind of bug report if runaway children refuse to
>> exit, please.
> 
> Well, there are various ways to make sure that child processes get SIGKILLed.
> The traditional way to do this is with process groups.

Err... I call setsid() because it's what the daemon() function usually does,
albeit filters run by courierfilter don't fork.  Probably, setpgid() or
setpgrp() are better choices.  (Let me recall that a session consists of one or
more program groups.)

> Probably the best thing to do would be to kill all the processes, but exit 
> with
> a non-zero exit code.

You're talking about courierfilter behavior, right?  Filters should kill all of
their child processes or threads when fd0 is closed.  However, if a filter
fails to do so, it deserves a SIGKILL.  Logging filtername is probably useful.

If a filter forked children, it may be worth to attempt to kill them too.  For
example, something like:

   pid_t p = pp->p;
   if (getpgid(p) != getpgid(getpid()))
      p = -p;
   kill(p, SIGKILL);

Alternatively, a new group can be created by courierfilter right after forking
each new filter.  That way, the "if" above is always true unless a filter
maliciously sets its group id back to courierfilter's one.

> systemd takes this one step further, and puts all systemd-started processes in
> a container. On Fedora, a shutdown is going to kill any stuck filter 
> processes,
> after filterctl stop bails out; so this is a non-issue on Fedora(*).

Hm...  filterctl may be invoked by hand, no?

> (*) This is not intended to be an endorsement of systemd.

Thank goodness :-)

Ale
-- 











































------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Reply via email to