[Openswan dev] [PATCH] Fix race condition between pluto start and whack
lazzer at vmlinux.org
Fri Apr 8 06:32:31 EDT 2011
On 04/08/11 08:23, D. Hugh Redelmeier wrote:
> | From: Mattias Walstrom <lazzer at vmlinux.org>
> | Fix race condition between pluto start and whack, which can result in
> | pluto becoming a zombie that never returns.
> Do you really mean "zombie"? A zombie is a process that has exited
> but hasn't been reaped by its parent. If pluto is running as a
> daemon, init should reap it.
Yes, it is marked as 'Z' in the process list. But it gets stuck like that, this does not happen all the time, but sometimes.
> Are you running pluto with --nofork?
> | When sending any whack message during the time pluto starts, whack will
> | just hang for a long time. And if pluto should die during this hang, it
> | will become a Zombie.
> I don't understand this. Why would a pending message cause Pluto to
> become a Zombie? This should not affect the ability of a parent
> process (init or otherwise) to reap it.
> | This patch makes sure that we do not open the ctl
> | socket until we actually can receive messages (all pluto initialization
> | is done).
> The code has a comment explaining why the socket is created where it
> is. I no longer am certain, but I think the idea was that once a
> startup script had executed "pluto", it was safe to assume that the
> socket was created. After your change, this is no longer true.
Yes, I noticed that comment, but I could not see the real reason for this, the socket will be useless until pluto setup is compeleted. It is not possible to communicate with pluto using whack until this is done.
I use an (slow) embedded system (arm, 400mhz), on which there is also another benefit of this patch; I use 'ipsec whack --status' to see if the tunnels have come up, but if you do this too soon after boot, 'ipsec whack' will not return until pluto has started (and processed the message, this takes 4-5 seconds), with this patch ipsec whack will return immediately if the socket does not exist.
> Dev mailing list
> Dev at openswan.org
More information about the Dev