[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
kill (0, SIGSTOP) is freezing the system (was: /hurd/init and /hurd/proc
From: |
Justus Winter |
Subject: |
kill (0, SIGSTOP) is freezing the system (was: /hurd/init and /hurd/proc) |
Date: |
Wed, 24 Jul 2013 08:30:52 +0200 |
Hi,
[PATCH 1/7] proc: add proc_mark_essential server code
[PATCH 2/7] hurd: add proc_mark_essential
[PATCH 3/7] init: Mark auth, proc and fs servers as essential
This is a refreshed but otherwise unmodified version of Guillems patch
series presented here:
http://lists.gnu.org/archive/html/bug-hurd/2006-02/msg00081.html
[PATCH 4/7] init: Build fixes
This seems to avoid the need to rebuild the libc.
[PATCH 5/7] proc: Fix miscalculation of count
This was the only issue I found with the patch.
[PATCH 6/7] proc: evil hack, mark all pids<100 essential
[PATCH 7/7] patch omitted
But unfortunately the patch series is only a small part of the
solution. To get a better picture of the problem, killall5 does the
following:
* kill (0, SIGSTOP)
* for all processes, read /proc/x/stat and kill it if it is not
classified as a kernel thread (or is the current process, or init,
or is in the same session, something like that).
* kill (0, SIGCONT)
The issues are:
* There are some processes that must not be frozen or the whole system
is affected. Hardcoding all processes below pid 100 to be essential
makes the system survive killall5, the processes below 100 that are
not marked as essential by Guillems patch are:
exec, /sbin/init, term, pflocal, mach-defpager, null, procfs,
proxy-defpager, tmpfs, storeio
I'm not sure about how important it is not to freeze anyone of them,
but at least procfs must not be stopped b/c killall5 wants to
iterate over /proc. But it would surely be nice not to freeze
filesystem translators, and probably the pagers and the term
translators.
* The question of whether killall5 kills a process or not is not at
all related to the 'kill (0, x) kills essential processes'
problem. killall5 parses /proc/*/stat and determines whether a
process is a kernel thread by looking at the startcode and endcode
fields.
/proc/*/stat: startcode and endcode fields are 0, making killall5
think that the process in question is a kernel thread and is
therefore not to be killed. So currently, killall5 does not kill any
processes on Hurd.
* As Markus pointed out in his critique of Guillems patch, any user
can mark any process as essential, this is probably not what we
want. Restricting this to root seems easy though.
So the main problem that I see is the question how to determine that a
process is essential in the first place. For some processes it is easy
to mark them after starting them, but for some this might be not
feasible. A lot of important translators are started by the root
filesystem for example.
Thoughts?
Justus
- Re: /hurd/init and /hurd/proc, Samuel Thibault, 2013/07/15
- Re: /hurd/init and /hurd/proc, Roland McGrath, 2013/07/15
- kill (0, SIGSTOP) is freezing the system (was: /hurd/init and /hurd/proc),
Justus Winter <=
- [PATCH 2/7] hurd: add proc_mark_essential, Justus Winter, 2013/07/24
- [PATCH 1/7] proc: add proc_mark_essential server code, Justus Winter, 2013/07/24
- [PATCH 4/7] init: Build fixes, Justus Winter, 2013/07/24
- [PATCH 3/7] init: Mark auth, proc and fs servers as essential, Justus Winter, 2013/07/24
- [PATCH 6/7] proc: evil hack, mark all pids<100 essential, Justus Winter, 2013/07/24
- [PATCH 5/7] proc: Fix miscalculation of count, Justus Winter, 2013/07/24
- Re: kill (0, SIGSTOP) is freezing the system (was: /hurd/init and /hurd/proc), Samuel Thibault, 2013/07/24