Re: [sage-support] Re: Zombie processes when using sage0 interface
On Mon, Feb 22, 2016 at 12:30 PM, Volker Braun wrote: > Every interfaces tries to launch the sage-cleaner. If it is already running, > the newly-forked sage-cleaner quits immediately. But there is nobody reaping > the child, so a zombie remains. > > The standard solutions are either > 1) waitpid in the parent e.g. whenever a new interface is created, > 2) double fork, then the sage-cleaner would be the grandchild adopted by > init > 3) SIGCHLD signal handler, which complicates further fork()s of sage > > > On Monday, February 22, 2016 at 8:27:55 PM UTC+1, William wrote: >> >> It depends on how Sage exits. If it exists properly then yes, they >> are killed. But Sage could exit by being "kill -9'" or by segfaulting >> or something else. Even then, it is important for the things Sage >> spawned to be killed. > > > IMHO an overall better design would be to have a monitor process for every > spawned sub-process instead of sage-cleaner being responsible for processes I agree. That's more how the "forever" monitor works in the world of node.js. It would be great if sage-cleaner were finally replaced. It was just a quick hack I wrote for an admin on a cluster somewhere in 2006, who were complaining that their users were leaving around sage zombie processes. I also don't know to what (if any) extent the once working-well-enough sage-cleaner got broken by subsequent code. > that are not its direct children. The current solution is definitely racy if > there is pid wraparound. > > -- > You received this message because you are subscribed to the Google Groups > "sage-support" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-support+unsubscr...@googlegroups.com. > To post to this group, send email to sage-support@googlegroups.com. > Visit this group at https://groups.google.com/group/sage-support. > For more options, visit https://groups.google.com/d/optout. -- William (http://wstein.org) -- You received this message because you are subscribed to the Google Groups "sage-support" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at https://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
Re: [sage-support] Re: Zombie processes when using sage0 interface
Every interfaces tries to launch the sage-cleaner. If it is already running, the newly-forked sage-cleaner quits immediately. But there is nobody reaping the child, so a zombie remains. The standard solutions are either 1) waitpid in the parent e.g. whenever a new interface is created, 2) double fork, then the sage-cleaner would be the grandchild adopted by init 3) SIGCHLD signal handler, which complicates further fork()s of sage On Monday, February 22, 2016 at 8:27:55 PM UTC+1, William wrote: > > It depends on how Sage exits. If it exists properly then yes, they > are killed. But Sage could exit by being "kill -9'" or by segfaulting > or something else. Even then, it is important for the things Sage > spawned to be killed. IMHO an overall better design would be to have a monitor process for every spawned sub-process instead of sage-cleaner being responsible for processes that are not its direct children. The current solution is definitely racy if there is pid wraparound. -- You received this message because you are subscribed to the Google Groups "sage-support" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at https://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
Re: [sage-support] Re: Zombie processes when using sage0 interface
On Sun, Feb 21, 2016 at 2:30 AM, Sho Takemori wrote:
> I also experienced this. (I use SageMath 7.0 on Ubuntu 15.10)
> I guess this is not specific to sage0. The following code will spawn five
> zombie processes.
>
> [a.eval("1") for a in [gp, gap, maxima, sage0, singular]]
>
> By debugging with pdb, I found that something is wrong with
> "sage.interfaces.cleaner.start_cleaner".
> I do not fully understand the purpose of start_cleaner. But I guess the
> parent process must wait until the child process spawned by "os.fork" exits,
> otherwise the child process ("sage-cleaner") becomes a zombie process.
> If I replace start_cleaner like this, zombie processes are not spawned.
>
> By the way, I do not understand why calling this function in gp.eval or
> gap.eval is necessary, since child processes (such as gp, gap) are killed
> when Sage exits.
It depends on how Sage exits. If it exists properly then yes, they
are killed. But Sage could exit by being "kill -9'" or by segfaulting
or something else. Even then, it is important for the things Sage
spawned to be killed.
>
> Sho Takemori
>
>
> 2016年2月19日金曜日 11時52分04秒 UTC+9 Daniel Lännström:
>>
>> I have noticed that when using the sage0 interface zombie processes remain
>> even after running the sage.interfaces.quit.expect_quitall function.
>>
>> Is this a bug? Is there some way to migrate this?
>>
>> Here is an example of what I am talking about. Here is the content of the
>> file zombie_test.sage
>>
>> import sage.interfaces.sage0
>> import sage.interfaces.quit
>>
>> def create_new_instances():
>> s = sage.interfaces.sage0.Sage()
>> s('4')
>> del s
>>
>> print "Create instances"
>> create_new_instances()
>> raw_input('continue?')
>> print "Run expect_quit"
>> sage.interfaces.quit.expect_quitall(verbose=True)
>> raw_input('continue?')
>>
>> After running the create_new_instances() function the relevant part of the
>> process tree looks like this.
>>
>> | | | `-bash,7619 /usr/lib/sagemath/local/bin/sage-python
>> zombie_test.sage.py
>> | | | |-python,7661
>> /usr/lib/sagemath/local/bin/sage-cleaner
>> | | | `-python,7663 zombie_test.sage.py
>> | | | |-python,7668
>> /usr/lib/sagemath/local/bin/sage-ipython --HistoryManager.hist_file=:memory:
>> ...
>> | | | `-(python,7669)
>>
>> But process 7669 is a zombie!
>>
>> PID TTY STAT TIME COMMAND
>> 7669 pts/6Z 0:00 [python]
>>
>> Next running sage.interfaces.quit.expect_quitall outputs
>>
>> Exiting Sage with PID 7668 running
>> /usr/lib/sagemath/local/bin/sage-ipython --HistoryManager.hist_file=:memory:
>> --colors=NoColor
>>
>> Indeed process 7668 has been removed but process 7669 remains and the
>> process tree looks like this:
>>
>> | | | `-bash,7619 /usr/lib/sagemath/local/bin/sage-python
>> zombie_test.sage.py
>> | | | |-python,7661
>> /usr/lib/sagemath/local/bin/sage-cleaner
>> | | | `-python,7663 zombie_test.sage.py
>> | | | |-(python,7668)
>> | | | |-(python,7669)
>> | | | `-python,7701 zombie_test.sage.py
>>
>> In my work I'm running a long executing program and these zombie processes
>> are annoying.
>>
>> Finally some info about my setup:
>> Sage Version 6.9, Release Date: 2015-10-10
>> Ubuntu MATE 15.10
>> Linux kernel 4.2.0-27-generic
>>
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-support" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-support+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-support@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-support.
> For more options, visit https://groups.google.com/d/optout.
--
William (http://wstein.org)
--
You received this message because you are subscribed to the Google Groups
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-support+unsubscr...@googlegroups.com.
To post to this group, send email to sage-support@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/d/optout.
