[PATCH] Allow binary upgrades in Solaris zones

[Maxim Dounin]

Hello!

On Thu, Jan 06, 2011 at 04:45:55PM +0000, doug at hcsw.org wrote:

> Hi Maxim,
> 
> On Thu, Jan 06, 2011 at 02:53:36AM +0300 or thereabouts, Maxim Dounin wrote:
> > Yes, nginx checks if previous upgrade was finished by checking 
> > parent pid to be 1.
> 
> Thank you for your explanation about this.
> 
> Does it also have something to do with preventing an upgrade when running
> nginx under daemontools?
> 
> "If you never did online upgrade before, this may mean that you run nginx
> under daemontools/etc. Thus online upgrade is not available in this case."
> 
> http://nginx.org/pipermail/nginx/2008-June/005678.html

With daemontools nginx binary upgrade will leave daemontools 
thinking nginx was terminated (and actually it was - but started 
another one before this), so it won't work anyway.

Running daemonized nginx though fghack[1] may help (usual 
restrictions apply, i.e. daemontools won't be able to send 
signals).

[1] http://cr.yp.to/daemontools/faq/create.html#fghack

> > I don't really like this aproach, it looks fragile and actually 
> > adds another non-portable hack instead of fixing original 
> > non-portability.
> 
> I agree it is a hack that relies on non-standard behaviour but I disagree
> that it is fragile. My logic behind the patch was that it should:
> 
> 1) Use only standard unix syscalls so as to not break compilation on any
>    platforms.
> 
> 2) Revert to the current behaviour and refuse upgrade if init process not
>    being visible inside zones does not apply.

Your patch relies on the following assumptions:

1. Process with pid 1 is visible if it's used as "default parent".

2. Process with pid 1 isn't visible if it's not used as "default 
parent".

Both may easily become false.

> > Probably passing real parent pid from old binary and checking if 
> > getppid() [doesn't] match whould be better aproach (at least, it 
> > should be portable).
> 
> Now that I understand the purpose behind this test better I agree this
> would be a better solution. I will look into creating a patch that
> implements this approach and post my results here.

That would be great, thanks.

Maxim Dounin