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
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
how
On Mon, 19.05.14 14:35, Brandon Black (blbl...@gmail.com) wrote:
On Fri, May 16, 2014 at 9:38 AM, Lennart Poettering
lenn...@poettering.netwrote:
On Thu, 15.05.14 20:57, Brandon Black (blbl...@gmail.com) wrote:
On Thu, May 15, 2014 at 6:40 PM, Lennart Poettering
On Fri, May 16, 2014 at 9:38 AM, Lennart Poettering
lenn...@poettering.netwrote:
On Thu, 15.05.14 20:57, Brandon Black (blbl...@gmail.com) wrote:
On Thu, May 15, 2014 at 6:40 PM, Lennart Poettering
lenn...@poettering.netwrote:
But again, it's generally not a good idea to keep file
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 pidfile
On Thu, 15.05.14 20:57, Brandon Black (blbl...@gmail.com) wrote:
On Thu, May 15, 2014 at 6:40 PM, Lennart Poettering
lenn...@poettering.netwrote:
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
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 /bin/kill -HUP
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 pidfile as
On Thu, May 15, 2014 at 6:40 PM, Lennart Poettering
lenn...@poettering.netwrote:
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
'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 asynchronism
'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 and read
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,
On Sun, May 4, 2014 at 11:19 PM, Gerd v. Egidy li...@egidy.de 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
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,
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
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's
]] 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 too.
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.
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 started
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/kill -HUP
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
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:
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
23 matches
Mail list logo
