Mantas Mikulėnas:
Maybe socket-activation would work for you? (With Nginx it's also a
hack though.)
Accept=No
Environment=NGINX=3;
It is not terrifically complex. The documented way to stop the forking
is "daemon off", but an inherited listening socket also does it.
* https://bugs.debian.o
On 7 June 2018 at 10:35, Lennart Poettering wrote:
> Nah, daemon() does not write PID files, you have to do that in your
> own code.
As daemon() calls _exit() (not even exit()) in the parent after the
fork, the only way to synchronize the pid writing is not to use the
daemon() at all and inline d
On Do, 07.06.18 09:50, Igor Bukanov (i...@mir2.org) wrote:
> On 18 May 2018 at 19:37, Lennart Poettering wrote:
> > On Do, 17.05.18 22:54, Igor Bukanov (i...@mir2.org) wrote:
> > Well, no. The protocol is clear, and what we do is pretty close to
> > black magic, and still racy in many ways.
> >
>
On Thu, 7 Jun 2018, Igor Bukanov wrote:
> On 18 May 2018 at 19:37, Lennart Poettering wrote:
> > On Do, 17.05.18 22:54, Igor Bukanov (i...@mir2.org) wrote:
> > Well, no. The protocol is clear, and what we do is pretty close to
> > black magic, and still racy in many ways.
> >
> > I mean, broken be
On 18 May 2018 at 19:37, Lennart Poettering wrote:
> On Do, 17.05.18 22:54, Igor Bukanov (i...@mir2.org) wrote:
> Well, no. The protocol is clear, and what we do is pretty close to
> black magic, and still racy in many ways.
>
> I mean, broken behaviour is still broken behaviour, even if we
> nowa
On Do, 17.05.18 22:54, Igor Bukanov (i...@mir2.org) wrote:
> On 17 May 2018 at 19:23, Lennart Poettering wrote:
>
> > So yes, this is a bug in nginx. They really should fix that. And this
> > is not only broken when you use systemd, but on sysvinit too, as a
> > command like this would likely fa
On 05/17/2018 03:54 PM, Igor Bukanov wrote:
Given that systemd deals with this situation in a very reasonable way,
nginx must not be alone in doing this. And if this a common way to
write such code, perhaps it should not be considered a bug but rather
one more peculiarity of application services
Am 17.05.2018 um 22:54 schrieb Igor Bukanov:
> On 17 May 2018 at 19:23, Lennart Poettering wrote:
>
>> So yes, this is a bug in nginx. They really should fix that. And this
>> is not only broken when you use systemd, but on sysvinit too, as a
>> command like this would likely fail there too: "s
On 17 May 2018 at 19:23, Lennart Poettering wrote:
> So yes, this is a bug in nginx. They really should fix that. And this
> is not only broken when you use systemd, but on sysvinit too, as a
> command like this would likely fail there too: "service nginx start
> service nginx status", as the sta
On Do, 17.05.18 13:18, Igor Bukanov (i...@mir2.org) wrote:
> Notice that there are 2 master processes, the old one with pid 2408
> and the one 2418. Initiate the shutdown of the initial master:
nginx can let PID 1 know about the new main PID by sending a MAINPID=
sd_notify() message.
Or even bet
On Do, 17.05.18 11:33, Reindl Harald (h.rei...@thelounge.net) wrote:
> > but that busy waits. Is there any option to replace this hack via a
> > native systemd solution, like explicitly waiting for the pid file to
> > appear before considering the unit ready?
>
> this is a bug in nginx
>
> howev
On Do, 17.05.18 11:25, Igor Bukanov (i...@mir2.org) wrote:
> Hi,
>
> I have a service unit for nginx that uses Type=forking and PIDFile.
> That works, but occasionally I see in the log a message like
>
> nginx.service: PID file /run/nginx/nginx.pid not readable (yet?) after
> start: No such file
On Thu, May 17, 2018 at 12:12:10PM +0200, Igor Bukanov wrote:
> On 17 May 2018 at 11:58, Mantas Mikulėnas wrote:
> > Have you tried without the PIDFile= setting at all?
>
> As far as I can see that breaks live updates that nginx supports where
> it starts a new process and workers and then gracef
On 17 May 2018 at 11:58, Mantas Mikulėnas wrote:
> this would be anyways broken because systemd reads the PIDFile once at
> start to dtermine MAINPID and if MAINPID goes away the service fails
This is not true as with PIDFile systemd does pick up the new process
as a new main without restarting t
On Thu, 17 May 2018, Igor Bukanov wrote:
> On 17 May 2018 at 12:07, Michael Chapman wrote:
> > It _is_ better for the PID file to be written out before the initial
> > process exits, but systemd will handle things correctly even if they
> > happen the other way around. Essentially the service won'
On 17 May 2018 at 12:07, Michael Chapman wrote:
> It _is_ better for the PID file to be written out before the initial
> process exits, but systemd will handle things correctly even if they
> happen the other way around. Essentially the service won't be considered
> to have completed activation un
On Thu, 17 May 2018, Igor Bukanov wrote:
> Hi,
>
> I have a service unit for nginx that uses Type=forking and PIDFile.
> That works, but occasionally I see in the log a message like
>
> nginx.service: PID file /run/nginx/nginx.pid not readable (yet?) after
> start: No such file or directory
>
>
Am 17.05.2018 um 12:12 schrieb Igor Bukanov:
> On 17 May 2018 at 11:58, Mantas Mikulėnas wrote:
>> Have you tried without the PIDFile= setting at all?
>
> As far as I can see that breaks live updates that nginx supports where
> it starts a new process and workers and then gracefully terminates
On 17 May 2018 at 11:58, Mantas Mikulėnas wrote:
> Have you tried without the PIDFile= setting at all?
As far as I can see that breaks live updates that nginx supports where
it starts a new process and workers and then gracefully terminates the
old main.
Regards, Igor
___
On Thu, May 17, 2018, 12:26 Igor Bukanov wrote:
> Hi,
>
> I have a service unit for nginx that uses Type=forking and PIDFile.
> That works, but occasionally I see in the log a message like
>
> nginx.service: PID file /run/nginx/nginx.pid not readable (yet?) after
> start: No such file or director
Am 17.05.2018 um 11:25 schrieb Igor Bukanov:
> I have a service unit for nginx that uses Type=forking and PIDFile.
> That works, but occasionally I see in the log a message like
>
> nginx.service: PID file /run/nginx/nginx.pid not readable (yet?) after
> start: No such file or directory
>
> Aft
Hi,
I have a service unit for nginx that uses Type=forking and PIDFile.
That works, but occasionally I see in the log a message like
nginx.service: PID file /run/nginx/nginx.pid not readable (yet?) after
start: No such file or directory
After investigating this father I see the reason for this i
22 matches
Mail list logo
