On Thu, 22.05.14 12:30, Alexander E. Patrakov (patra...@gmail.com) wrote:
> I guess that the text needs to be clarified, as currently it is a
> source of long-living locks on PID-files, with the associated
> vulnerabilities.
I simply removed that sentence now, to not create confusion regarding
ho
05.05.2014 21:14, Lennart Poettering wrote:
On Mon, 05.05.14 10:00, Gerd v. Egidy (li...@egidy.de) wrote:
systemd will behave as expected: once your main process terminates it will
re-read PID
from this file (assuming that before dying your old process writes its
child's PID) and set it as MAIN
On Mon, 19.05.14 14:35, Brandon Black (blbl...@gmail.com) wrote:
> On Fri, May 16, 2014 at 9:38 AM, Lennart Poettering
> wrote:
>
> > On Thu, 15.05.14 20:57, Brandon Black (blbl...@gmail.com) wrote:
> >
> > > On Thu, May 15, 2014 at 6:40 PM, Lennart Poettering
> > > wrote:
> > > >
> > > > But aga
On Fri, May 16, 2014 at 9:38 AM, Lennart Poettering
wrote:
> On Thu, 15.05.14 20:57, Brandon Black (blbl...@gmail.com) wrote:
>
> > On Thu, May 15, 2014 at 6:40 PM, Lennart Poettering
> > wrote:
> > >
> > > But again, it's generally not a good idea to keep file locks for a
> > > longer period of t
Hi Кирилл,
> > What's wrong with writing the new pid from the old proccess before
> > releasing the lock?
>
> So unless someone else has a better idea I'll try this approach and report
> back.
I tried this now and it works as you described. Will work on a true solution
based on rewriting the pi
On Thu, 15.05.14 20:57, Brandon Black (blbl...@gmail.com) wrote:
> On Thu, May 15, 2014 at 6:40 PM, Lennart Poettering
> wrote:
> >
> > But again, it's generally not a good idea to keep file locks for a
> > longer period of time, much as with mutexes... You don't want to make
> > other apps which
On Thu, May 15, 2014 at 6:40 PM, Lennart Poettering
wrote:
>
> But again, it's generally not a good idea to keep file locks for a
> longer period of time, much as with mutexes... You don't want to make
> other apps which try to get an atomic view on the file hang for long.
>
If they don't want to
On Mon, 05.05.14 23:28, Gerd v. Egidy (li...@egidy.de) wrote:
>
> > Generally, it's not a good idea to keep file locks for a longer period
> > of time... YOu should really just take them while you write a file, and
> > then release them, but not keep them forever...
>
> I keep the lock on the pi
On Wed, 07.05.14 09:02, Colin Guthrie (gm...@colin.guthr.ie) wrote:
>
> 'Twas brillig, and Gerd v. Egidy at 05/05/14 22:17 did gyre and gimble:
> >> > Secondly, the killing is asynchronous.
> > When looking at
> > http://www.freedesktop.org/software/systemd/man/systemd.service.html
> > I see "/b
'Twas brillig, and Lennart Poettering at 05/05/14 16:27 did gyre and gimble:
>> > ExecStart=/usr/sbin/icinga2 -c ${ICINGA2_CONFIG_FILE} -d -e
>> > ${ICINGA2_ERROR_LOG} -u ${ICINGA2_USER} -g ${ICINGA2_GROUP}
> I'd recommend teaching the daemon to find its own config file when none
> is specified an
'Twas brillig, and Gerd v. Egidy at 05/05/14 22:17 did gyre and gimble:
>> > Secondly, the killing is asynchronous.
> When looking at
> http://www.freedesktop.org/software/systemd/man/systemd.service.html
> I see "/bin/kill -HUP $MAINPID" recommended. How is this different in regards
> to asynchr
> Generally, it's not a good idea to keep file locks for a longer period
> of time... YOu should really just take them while you write a file, and
> then release them, but not keep them forever...
I keep the lock on the pidfile as long as the daemon is running. I think this
is the best way to pre
Hi Lennart,
thanks for your tips.
> > EnvironmentFile=/etc/sysconfig/icinga2
>
> This is a Fedoraism/Redhatism, I can only recommend not adding something
> like this to upstream projects.
You are right. Will think of an alternative way that works everywhere.
> > ExecReload=/bin/sh -c '/bin/kil
On Sun, 04.05.14 23:19, Gerd v. Egidy (li...@egidy.de) wrote:
> [Unit]
> Description=Icinga host/service/network monitoring system
> After=syslog.target postgresql.service mariadb.service
No need to mention "syslog.target" here anymore, this is actually
implied, as any systemd service is now star
On Mon, 05.05.14 10:00, Gerd v. Egidy (li...@egidy.de) wrote:
> > systemd will behave as expected: once your main process terminates it will
> > re-read PID
> > from this file (assuming that before dying your old process writes its
> > child's PID) and set it as MAINPID for your service.
>
> Hmm.
]] "Gerd v. Egidy"
> So unless someone else has a better idea I'll try this approach and report
> back.
When you fork off the child, also open a pipe and use that to
communicate over, rather than signals, then you can easily make it into
an extensible protocol if you need richer communication t
Hi Кирилл,
> I've just tested the way I described it and everything worked perfectly.
Thanks.
> What's wrong with writing the new pid from the old proccess before
> releasing the lock?
To get it right I have to take care of two cases of SIGTERM in the old daemon:
a) the new process checked it'
Hi Umut,
> > Can you describe the downsides of GuessMainPID=no more specific than
> > "failure detection and automatic restarting of a service will not work
> > reliably"?
> One down side I can mention is for the fault recovery. If your
> application crashes and if systemd is configured to restart
I've just tested the way I described it and everything worked perfectly.
Definitely the issue is this short period of time, I'm almost sure
(didn't check the source, though) that systemd re-reads pidfile
the moment the main process terminates.
What's wrong with writing the new pid from the old pro
Hi Кирилл,
> OK, I've just re-read your message and it looks like all you need is add
> `PIDFile` to your unit.
This was the first thing I tried when writing the service file. Unfortunately
it
does not work, the service is declared dead and the new daemon is killed
(unless I switch off killing
Hi,
On Sun, May 4, 2014 at 11:19 PM, Gerd v. Egidy wrote:
> Hi,
>
> I'm one of the developers of the Icinga monitoring system. We want to provide
> a .service file for our monitoring daemon with the next major release (Icinga
> 2).
>
> Due to technical reasons, the daemon can't reload it's confi
OK, I've just re-read your message and it looks like all you need is add
`PIDFile` to your unit.
systemd will behave as expected: once your main process terminates it will
re-read PID
from this file (assuming that before dying your old process writes its
child's PID) and
set it as MAINPID for your
Hi Кирилл,
> Have you looked into using sd_notify to update MAINPID?
No, not yet. I have sd_notify on my list of things to look at in the future,
but I wanted to make the service work without changing the daemon itself first.
Thanks for the hint about this possibility.
Kind regards,
Gerd
___
Have you looked into using sd_notify to update MAINPID?
--
Кирилл Елагин
On Mon, May 5, 2014 at 1:19 AM, Gerd v. Egidy wrote:
> Hi,
>
> I'm one of the developers of the Icinga monitoring system. We want to
> provide
> a .service file for our monitoring daemon with the next major release
> (Ic
Hi,
I'm one of the developers of the Icinga monitoring system. We want to provide
a .service file for our monitoring daemon with the next major release (Icinga
2).
Due to technical reasons, the daemon can't reload it's configuration files
within one process. So we implement reload like this:
25 matches
Mail list logo
