From: Silas S. <si...@gm...> - 2012-11-12 02:06:44
|
Hi all! I use ion3 and now notion for about 4 years, first in GNU/Linux and now in NetBSD. In NetBSD, I started to customize my statusbar with statusd scripts, adapting some from contrib and making some of them myself. But, I had to make some ugly changes on them. In order to make external commands work, I had to add os.execute("sleep 1") just after io.popen(). Yes, it worked and since I didn't have time to investigate the problem, I worked that way a long time. Now I decided to investigate the problem further. I made a small statusd_test.lua script: local test_timer = statusd.create_timer() local function update_test() local f = io.popen('echo x', 'r') os.execute("sleep 1") local value = f:read('*all') statusd.inform("test", value) test_timer:set(1000, update_test) end update_test() Without os.execute("sleep 1"), I receive: test: x . test: (null) . test: (null) ... But, with os.execute("sleep 1"), it works fine. I soon realized that time events were generated by SIGALRM. So there could be anything related with signals. So, my investigations confirm that a minor change is necessary to make it work. Just comment line 543 of libmainloop/signal.c: sigaction(SIGCHLD, &sa, NULL); And it works like a charm, but I don't know if it breaks other things. I'm not a C programmer expert. So I'd like to ask you if you know why it could be happening. If it works under GNU/Linux, it is probably something regarding implementation of signals in NetBSD. Do you have any idea? Why SIGCHLD is being intercepted? Thanks in advance. -- Silas Silva |
From: Silas S. <si...@gm...> - 2012-11-12 12:04:01
|
On Mon, Nov 12, 2012 at 12:06:02AM -0200, Silas Silva wrote: > In order to make external commands work, I had to add os.execute("sleep > 1") just after io.popen(). Yes, it worked and since I didn't have time > to investigate the problem, I worked that way a long time. Now I see that the workaround is not related to sleep, but to any process I execute with os.execute(). Now the SIGCHLD stuff starts to make sense... -- Silas Silva |
From: Arnout E. <no...@bz...> - 2012-11-13 16:39:02
|
On Mon, Nov 12, 2012 at 12:06:02AM -0200, Silas Silva wrote: > I soon realized that time events were generated by SIGALRM. So there > could be anything related with signals. So, my investigations confirm > that a minor change is necessary to make it work. Just comment line 543 > of libmainloop/signal.c: > > sigaction(SIGCHLD, &sa, NULL); > > And it works like a charm, but I don't know if it breaks other things. > > I'm not a C programmer expert. So I'd like to ask you if you know why > it could be happening. If it works under GNU/Linux, it is probably > something regarding implementation of signals in NetBSD. > > Do you have any idea? > > Why SIGCHLD is being intercepted? I haven't looked *too* closely yet, but it seems this is used somehow in libmainloop. Looks like it is used to provide a 'mainloop_sigchld_hook' hook, but I don't see this hook actually being used anywhere. Anyone? Arnout |
From: Silas S. <si...@gm...> - 2013-01-11 14:38:28
|
On Tue, Nov 13, 2012 at 05:23:40PM +0100, Arnout Engelen wrote: > On Mon, Nov 12, 2012 at 12:06:02AM -0200, Silas Silva wrote: > > I soon realized that time events were generated by SIGALRM. So there > > could be anything related with signals. So, my investigations confirm > > that a minor change is necessary to make it work. Just comment line 543 > > of libmainloop/signal.c: > > > > sigaction(SIGCHLD, &sa, NULL); > > > > And it works like a charm, but I don't know if it breaks other things. Yes, months later I see it breaks other things. Details below. :-/ > > Why SIGCHLD is being intercepted? > > I haven't looked *too* closely yet, but it seems this is used somehow in > libmainloop. Looks like it is used to provide a 'mainloop_sigchld_hook' hook, > but I don't see this hook actually being used anywhere. Without that line, spawned processes (sh) are dead (zombie), but do not free the pid. In systems with small number of allowed processes per user (ulimit -p), like mine (my NetBSD environment), soon it reaches the situation where I run out of resources and fork() fail. I tested it under NetBSD (5.1) and Ubuntu GNU/Linux (12.10). This behaviour (creation of zombie process without the sigaction() line) is the same on both. Maybe understand that snippet of code and add comments are valuable. I intend to investigate the problem further, to allow correct behaviour of statusd in NetBSD and do not allow the creation of zombie process. Thanks for now! :-) -- Silas Silva |
From: Silas S. <si...@gm...> - 2013-01-11 19:47:32
|
On Fri, Jan 11, 2013 at 12:35:09PM -0200, Silas Silva wrote: > Without that line, spawned processes (sh) are dead (zombie), but do not > free the pid. In systems with small number of allowed processes per > user (ulimit -p), like mine (my NetBSD environment), soon it reaches the > situation where I run out of resources and fork() fail. Of course. This is expected, since the parent is not called wait() anymore. I'm back to the ion-statusd problem (see the first e-mail of this thread). Going to study it further. Thank you for now. -- Silas Silva |