That's it.
Yep, I can see it in the `journalctl` but it's not in `journalctl -u
servicename`
Thanks
On 18 May 2018 at 11:44, Michael Biebl wrote:
> 2018-05-17 23:02 GMT+02:00 Ivan Kurnosov :
>
> > Here is the example of the `journald` output for the service:
>
> I assume you used journalctl -u
2018-05-17 23:02 GMT+02:00 Ivan Kurnosov :
> Here is the example of the `journald` output for the service:
I assume you used journalctl -u bla.service?
If so, do the log messages turn up if you run journalctl?
Then this might be another instance of
https://github.com/systemd/systemd/issues/2913
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
Hi,
I originally asked this question on the stackoverflow (
https://stackoverflow.com/q/50400145/251311) but I feel I wouldn't get an
answer there.
The simplified example that demonstrates a problem is
#include
int main(void)
{
printf("foo\n");
fflush(stdout);
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 05/16/2018 11:52 PM, Lennart Poettering wrote:
Hence, please go aahead and drop it from the rpm scripts.
Thanks for the clear advice. I filed
https://bugzilla.redhat.com/show_bug.cgi?id=1579225
to track the removal.
Florian
___
systemd-devel
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
19 matches
Mail list logo
