Re: [OT OBSD Programming] kill cu processes

["Marcus Andree S. Magalhaes" <marcus.magalhaes@vlinfo.com.br>]

> hi all!
>
> in a project I am involved in we connect to a serial device using cu.
> we fork() and execvp() the cu programm keeping two pipes. one for
> reading one for writing. this runs very smoothly. ;-)

hmmmm sounds a bit weird, but if it works, then it works! ;) Besides,
I have no clue about the characteristics and features your system should
have.

>
> but on openbsd cu seems to for itself a second time. having two
                                ^
                                |
I hope there is a "k" here -----+

> processes listed. I guess this is to do asynchronous io, since pthreads
> are implemented in userland on obsd..
>
> this is no problem until we want to exit.
> how can our programm, that has done the fork() of cu, kill _both_ cu
> processes. right now the self-forked cu process remains as a zombie. we
> don't want this of course..
>

I'm assuming youve checked the ppid of the 2nd cu process and found that
the 1st cu process really forked or exec'ed a 2nd instance of cu.

Zeroth: check if you aren't killing the master cu with a sigkill instead
of a sigterm. If cu is murdered by a sigkill, there's no way to wait()
its child to exit cleanly first before a exit().

First, try to mimic that self forking cu behavior. Send a sigterm to
the parent program and see if there's any zombie process lying around.
If you can safely send a sigterm to the "master" cu program, then your
program should do it safely also.

Second. Serial is slow. Maybe, even if you send a sigterm to the main
cu program, someone has decided that that it shouldn't wait() its
child to exit cleanly and, instead, it should exit itself, deliberately
leaving this wait() task to init. IMHO, it's a bad design.

Third. If nothing works, your program can always to traverse the proc
structure, find which processes have your program pid as a ppid and
sigterm, sigkill or (maybe) wait() them instead of leaving a zombie
to init.

Finally, be careful with sigkilling programs that deal with serial ports.
Things may go awry easily.

>
> any hint?
>
>
> regards
> /christian