> 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
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 do
Hi Bruce,
On Mon, May 5, 2014 at 6:15 PM, Bruce Dubbs wrote:
> 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.
Have you checked that your kernel has all the required config options
enabled? In par
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
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 ar
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.
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 thi
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 bee
On Mon, May 5, 2014 at 2:35 PM, Robert Milasan wrote:
> 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 de
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 /sys/class/net/e
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 flag.
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 sys
]] "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
20 matches
Mail list logo
