On 17:30 Thu 12 Oct , William Lallemand wrote:
> On Thu, Oct 12, 2017 at 05:50:52PM +0300, Apollon Oikonomopoulos wrote:
> > Yes, there are. systemd will only perform a single operation on a
> > unit at a time, and will queue up the rest. When you inform systemd
> > that something (startup/re
On Thu, Oct 12, 2017 at 05:50:52PM +0300, Apollon Oikonomopoulos wrote:
> >
> > One helpful feature I read in the documentation is the usage of the
> > sd_notify(.. "READY=1"). It can be useful for configuration files that
> > takes
> > time to process, for example those with a lot of ssl front
On 16:17 Thu 12 Oct , William Lallemand wrote:
> Hi,
>
> On Thu, Oct 12, 2017 at 01:19:58PM +0300, Apollon Oikonomopoulos wrote:
> > The biggest issue here is that we are using a signal to trigger the
> > reload (which is a complex, non-atomic operation) and let things settle
> > on their ow
Hi,
On Thu, Oct 12, 2017 at 01:19:58PM +0300, Apollon Oikonomopoulos wrote:
> The biggest issue here is that we are using a signal to trigger the
> reload (which is a complex, non-atomic operation) and let things settle
> on their own. Systemd assumes that as soon as the signal is delivered
> (
Hi all,
On 22:01 Wed 04 Oct , Lukas Tribus wrote:
> Hello Moemen,
>
>
> Am 04.10.2017 um 19:21 schrieb Moemen MHEDHBI:
> >
> > I am wondering if this is actually an expected behaviour and if maybe
> > that restart/stop should just shutdown the process and its open connections.
> > I have mad
On 17-10-08 21:55:37, William Lallemand wrote:
> * To change the KillMode to the default, which should kill -SIGTERM
> all processes on a stop or restart. But if I remember well, it leads
> to a bad exit code on the systemd side and display an error.
There is SuccessExitStatus [1] which might help
On Fri, Oct 06, 2017 at 05:04:18PM +0200, Moemen MHEDHBI wrote:
> Hi Lukas,
>
>
> On 04/10/2017 22:01, Lukas Tribus wrote:
> > I guess the problem is that when a reload happens before a restart and
> > pre-reload
> > systemd-wrapper process is still alive, systemd gets confused by that old
> >
Hi Lukas,
On 04/10/2017 22:01, Lukas Tribus wrote:
> I guess the problem is that when a reload happens before a restart and
> pre-reload
> systemd-wrapper process is still alive, systemd gets confused by that old
> process
> and therefor, refrains from starting up the new instance.
>
> Or syste
Hi all,
Thanks for the responses.
I agree, in most cases having Ansible trigger a reload instead of a restart
is better and it will prevent the situation I described. We have a few
environments with very long running sessions where there are situations
that we change the configuration and configu
Hello Moemen,
Am 04.10.2017 um 19:21 schrieb Moemen MHEDHBI:
>
> I am wondering if this is actually an expected behaviour and if maybe
> that restart/stop should just shutdown the process and its open connections.
> I have made the following tests:
> 1/ keep an open connection then do a restart w
Hi Lukas,
On 04/10/2017 18:57, Lukas Tribus wrote:
> Hello Niels,
>
>
> a restart means stopping haproxy - and after haproxy exited completely,
> starting haproxy again. When that happens, haproxy immediately stops
> listening to the sockets and then waits for existing connections to be
> closed
Hello Niels,
a restart means stopping haproxy - and after haproxy exited completely,
starting haproxy again. When that happens, haproxy immediately stops
listening to the sockets and then waits for existing connections to be
closed (you can accelerate that with hard-stop-after [1], but that's not
Hello,
First time mailing here, so hopefully I'm at the right place.
I use Ansible to deploy our haproxy configuration, and the following
scenario might happen:
1. Haproxy is running on an existing system
2. I execute the Ansible playbook.
3. This playbook changes the haproxy config (which will t
13 matches
Mail list logo
