Re: [PATCH v2 1/1] MEDIUM: mworker: Add systemd `Type=notify` support

Hi Tim, The change in the unit file seems legitimate, and the USE_SYSTEMD build option is fine, however I think we can improve slighly the patch. I think a good way to activate this feature will be to use it with a -Ws command line option instead of changing the behavior of the -W one. This way

Re: [PATCH v2 1/1] MEDIUM: mworker: Add systemd `Type=notify` support

Hi again, On Sun, Nov 19, 2017 at 03:10:21AM +0100, Tim Düsterhus wrote: > diff --git a/contrib/systemd/haproxy.service.in > b/contrib/systemd/haproxy.service.in > index 81b4951df..895e3b036 100644 > --- a/contrib/systemd/haproxy.service.in > +++ b/contrib/systemd/haproxy.service.in > @@ -11,8

Re: [PATCH v2 1/1] MEDIUM: mworker: Add systemd `Type=notify` support

William, Am 20.11.2017 um 11:11 schrieb William Lallemand: > On Sun, Nov 19, 2017 at 03:10:21AM +0100, Tim Düsterhus wrote: >> +KillSignal=USR1 > > In my opinion this part is a problem, it won't stop the process immediatly > but wait for session to be finished. It will cause the restart to

Re: [PATCH v2 1/1] MEDIUM: mworker: Add systemd `Type=notify` support

William, Am 20.11.2017 um 12:01 schrieb William Lallemand: >> The only difference I can see is that haproxy will fail to start for a >> different reason (use of undefined option, instead of not sending the >> READY=1 notification) if one uses the provided unit file *without* >> compiling with

Re: [PATCH v2 1/1] MEDIUM: mworker: Add systemd `Type=notify` support

Willy, Am 20.11.2017 um 12:04 schrieb Willy Tarreau: > But from what you explained (or at least what I understood), the mode > specified in the unit file needs to match the build option. This is If `Type=notify` is set then `USE_SYSTEMD` must be provided at build time, yes. But as I outlined

Re: [PATCH v3 1/1] MEDIUM: mworker: Add systemd `Type=notify` support

On Mon, Nov 20, 2017 at 03:58:35PM +0100, Tim Düsterhus wrote: > From: Tim Duesterhus > > This patch adds support for `Type=notify` to the systemd unit. Looks good to me, thanks! Willy can you merge it? -- William Lallemand

Re: [PATCH v3 0/1] MEDIUM: mworker: Add systemd `Type=notify` support

On Mon, Nov 20, 2017 at 03:58:34PM +0100, Tim Düsterhus wrote: > Coming along is a patch that implements your suggested changes. > > Two things: > - I was unsure whether to renumber the GTUNE_* constants. I opted not to. Not needed. It might be a cleanup for later. However I moved your

RE: AWS re:Invent Exibitors - Attendees List

Thanks for getting in touch mate. How did you track me down? I’d prefer if we use this email address though cos my ex girlfriend still uses the one you emailed. She can’t be trusted aye.

Re: haproxy-1.8-rc4 - FreeBSD 11.1 - master-worker daemon mode does not bind.?.

A little bump.. Wondering if the truss attachments maybe got my mail blocked.. ( the mail doesn't show on https://www.mail-archive.com/haproxy@formilux.org/maillist.html ) They where 107KB total in 2 attachments.. Now in 0bin links:

Re: haproxy-1.8-rc4 - FreeBSD 11.1 - build error: undefined reference, plock.h __unsupported_argument_size_for_pl_try_s__

On Mon, Nov 20, 2017 at 06:18:43AM +0100, Willy Tarreau wrote: > > Not sure if it still matters but for the record my cc -v output: > > root@:/usr/ports/net/haproxy-devel # cc -v > > FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM > > 4.0.0) > > Target:

Re: [RFC] Wireshark dissector for SPOP

Hi Fred,   thanks for looking into this, I've fixed this issue (and introduced some new :-))   The attached dissector code parses all SPOP frames sent from contrib/spoa_sample and haproxy and handles some fragmentation scenarios.   Kind regards,       Danny     Gesendet: Sonntag, 19.

Re: haproxy-1.8-rc4 - FreeBSD 11.1 - master-worker daemon mode does not bind.?.

Hi Willy, Op 20-11-2017 om 21:46 schreef Willy Tarreau: Hi Pieter, On Mon, Nov 20, 2017 at 01:47:48AM +0100, PiBa-NL wrote: Hmmm thinking about it there might be something. Could you start with "-dk" to disable kqueue and fall back to poll ? kqueue registers a post- fork function to close and

Re: haproxy-1.8-rc4 - FreeBSD 11.1 - master-worker daemon mode does not bind.?.

On Mon, Nov 20, 2017 at 10:18:31PM +0100, PiBa-NL wrote: > Hi Willy, > > Op 20-11-2017 om 22:08 schreef Willy Tarreau: > > OK thank you. I suspect something wrong happens, such as the master > > killing the same kevent_fd as the other ones are using or something > > like this. > > > > Could you

Re: haproxy-1.8-rc4 - FreeBSD 11.1 - master-worker daemon mode does not bind.?.

Hi Pieter, On Mon, Nov 20, 2017 at 01:47:48AM +0100, PiBa-NL wrote: > Hi List, > > After compiling haproxy 1.8-rc4 (without modifications) on FreeBSD11.1 i'm > trying to run it with master-worker option. > > I can run it with the following config from a ssh console: > > global >     #daemon >  

AWS Reinvent 2017 Verified Attendees list

Hi, Hope you are keeping well, Did you get a chance to look at my E-mail as I would like to know if you are interested in the data for your marketing advantages? Regards, Michael Smith --- This email has been checked for viruses by Avast antivirus software.

Re: haproxy-1.8-rc4 - FreeBSD 11.1 - master-worker daemon mode does not bind.?.

Hi Willy, Op 20-11-2017 om 22:08 schreef Willy Tarreau: OK thank you. I suspect something wrong happens, such as the master killing the same kevent_fd as the other ones are using or something like this. Could you please try the attached patch just in case it fixes anything ? I have not

Re: haproxy-1.8-rc4 - FreeBSD 11.1 - master-worker daemon mode does not bind.?.

Hi Pieter, On Mon, Nov 20, 2017 at 09:17:12PM +0100, PiBa-NL wrote: > A little bump.. Wondering if the truss attachments maybe got my mail > blocked.. ( the mail doesn't show on > https://www.mail-archive.com/haproxy@formilux.org/maillist.html ) > They where 107KB total in 2 attachments.. Now in

Re: haproxy-1.8-rc4 - FreeBSD 11.1 - master-worker daemon mode does not bind.?.

On Mon, Nov 20, 2017 at 10:02:57PM +0100, PiBa-NL wrote: > Hi Willy, > Op 20-11-2017 om 21:46 schreef Willy Tarreau: > > Hi Pieter, > > > > On Mon, Nov 20, 2017 at 01:47:48AM +0100, PiBa-NL wrote: > > > Hmmm thinking about it there might be something. Could you start with > > > "-dk" to disable

Re: [PATCH v3 1/1] MEDIUM: mworker: Add systemd `Type=notify` support

Hello Tim, 2017-11-20 15:58 GMT+01:00 Tim Düsterhus : > From: Tim Duesterhus > > This patch adds support for `Type=notify` to the systemd unit. > > Supporting `Type=notify` improves both starting as well as reloading > of the unit, because systemd will be

haproxy-1.8-rc4 - FreeBSD 11.1 - master-worker daemon parent staying alive/process-owner

Hi List, I've got a startup script that essentially looks like the one below #1# (simplified..) When configured with master-worker, the first parent process 2926 as seen in #2# keeps running. Doing the same without master-worker, the daemon properly detaches and the parent exits returning

Re: haproxy-1.8-rc4 - FreeBSD 11.1 - master-worker daemon parent staying alive/process-owner

Hi, On Tue, Nov 21, 2017 at 02:13:24AM +0100, PiBa-NL wrote: > Hi List, > > I've got a startup script that essentially looks like the one below #1# > (simplified..) > When configured with master-worker, the first parent process 2926 as > seen in #2# keeps running. Yes, that's the expected

Re: HAProxy SMTP Rate limiting

HI: Thanks for the reply. Your theory is absolutely correct. Though we could not print out the logs, we did the following to confirm: 1. Changed acl to acl isfail res.payload(0,3) -m beg 220 2. We could see the gpc0 getting hit and incremented. So this means that our

Re: [PATCH v3 1/1] MEDIUM: mworker: Add systemd `Type=notify` support

Hi Lukas, On Tue, Nov 21, 2017 at 01:12:10AM +0100, Lukas Tribus wrote: > 2017-11-20 15:58 GMT+01:00 Tim Düsterhus : > > From: Tim Duesterhus > > > > This patch adds support for `Type=notify` to the systemd unit. > > > > Supporting `Type=notify` improves

Re: [PATCH v3 1/1] MEDIUM: mworker: Add systemd `Type=notify` support

On Tue, Nov 21, 2017 at 07:16:19AM +0100, Willy Tarreau wrote: > > I really don't like this. My fears with becoming more systemd-friendly > was that we'd make users helpless when something decides not to work > just to annoy them, and this reports seems to confirm this feeling :-/ > > Tim, have

Re: [PATCH v2 1/1] MEDIUM: mworker: Add systemd `Type=notify` support

William, Am 20.11.2017 um 13:45 schrieb William Lallemand: > On Mon, Nov 20, 2017 at 12:55:06PM +0100, Tim Düsterhus wrote: >> May I suggest the following: If haproxy is *not* compiled with the >> `USE_SYSTEMD` option it checks for the existence of the `NOTIFY_SOCKET` >> environment variable and

Re: [PATCH v2 1/1] MEDIUM: mworker: Add systemd `Type=notify` support

On Mon, Nov 20, 2017 at 12:55:06PM +0100, Tim Düsterhus wrote: > William, > > Am 20.11.2017 um 12:01 schrieb William Lallemand: > >> The only difference I can see is that haproxy will fail to start for a > >> different reason (use of undefined option, instead of not sending the > >> READY=1

Re: [PATCH v2 1/1] MEDIUM: mworker: Add systemd `Type=notify` support

William, Am 20.11.2017 um 10:59 schrieb William Lallemand: > I think a good way to activate this feature will be to use it with a -Ws > command > line option instead of changing the behavior of the -W one. > > This way we can integrate the -Ws command in the unit file without changing > the >

Re: [PATCH v2 1/1] MEDIUM: mworker: Add systemd `Type=notify` support

On Mon, Nov 20, 2017 at 11:39:53AM +0100, Tim Düsterhus wrote: > William, > > Am 20.11.2017 um 10:59 schrieb William Lallemand: > > I think a good way to activate this feature will be to use it with a -Ws > > command > > line option instead of changing the behavior of the -W one. > > > > This

Re: [PATCH v2 1/1] MEDIUM: mworker: Add systemd `Type=notify` support

Hi Tim, On Mon, Nov 20, 2017 at 11:39:53AM +0100, Tim Düsterhus wrote: > William, > > Am 20.11.2017 um 10:59 schrieb William Lallemand: > > I think a good way to activate this feature will be to use it with a -Ws > > command > > line option instead of changing the behavior of the -W one. > > >

[PATCH v3 1/1] MEDIUM: mworker: Add systemd `Type=notify` support

From: Tim Duesterhus This patch adds support for `Type=notify` to the systemd unit. Supporting `Type=notify` improves both starting as well as reloading of the unit, because systemd will be let known when the action completed. See this quote from `systemd.service(5)`: > Note

[PATCH v3 0/1] MEDIUM: mworker: Add systemd `Type=notify` support

Willy, > I really don't like this at all, because it means that we'll annoy all > the happy people who are not forced to suffer from systemd, ie basically > all those not running on a recent linux distro, simply because we're starting > to declare that certain environment variables only belong to