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