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.
Hi Austin,
this does sound like a use-case for RuntimeDirectory=. See
http://www.freedesktop.org/software/systemd/man/systemd.exec.html for
details. That is simpler and makes sure the directory is
created/cleaned up as needed by systemd as the job is started/stopped.
That is available since
Hello.
During my testing of systemd pam sessions i discovered that pam session is not
closed automatically when i specify KillUserProcesses=yes in latest versions.
Investigations showed that since in pam module we started to dup fifo
descriptor problem appeared. Dup does not set O_CLOEXEC
Hello, seems that on some systems (in our cases s390x) a dual
port network device, is named ens11 and ens11d1 which doesn't exactly
looks normal (not sure if this in on purpose or not)
udevadm info -a -p /sys/class/net/ens11 | grep dev_id
ATTR{dev_id}==0x0
udevadm info -a -p
On Fri, 02.05.14 13:19, Florian Weimer (fwei...@redhat.com) wrote:
On 05/02/2014 01:05 PM, Lennart Poettering wrote:
No, /dev/random can (and will) block long after booting.
But that's what you want in this case, no? You want this to block after
booting if there never has been enough
On Wed, 30.04.14 17:06, Florian Weimer (fwei...@redhat.com) wrote:
On 04/30/2014 02:28 PM, Daniel P. Berrange wrote:
Interesting suggestion. I just used virt-manager to create the VM.
I don't see any trace for rng or random in the domain XML file.
If it is supported, I think it should be
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
On Fri, 02.05.14 12:54, Daniel J Walsh (dwa...@redhat.com) wrote:
On 05/02/2014 11:54 AM, Lennart Poettering wrote:
On Wed, 30.04.14 14:21, Daniel J Walsh (dwa...@redhat.com) wrote:
http://rhatdan.wordpress.com/2014/04/30/running-systemd-within-a-docker-container/
There are a couple
I am trying to get systemd to work with an LFS system (systemd-212).
When I try to boot, all the partitions, including swap, in fstab time out.
# file system mount-point type options dump fsck
# order
/dev/sda6
Hello.
During my testing of systemd pam sessions i discovered that session processes
are not deleted automatically when i specify KillUserProcesses=yes in latest
versions of systemd.
Investigations showed that since in pam_systemd.so we started to dup() fifo
descriptor problem appeared. Dup
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
18 matches
Mail list logo
