Hello!

On Thu, Jan 06, 2011 at 04:45:55PM +0000, doug@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

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://nginx.org/mailman/listinfo/nginx-devel