Applied the patch to 1.6-dev5, using exactly same configuration as I sent
over earlier on both of my haproxy instances. stick table entries are being
synced from A->B but not B->A. I have tried using single process too. Any
idea what could be wrong here?
- Pradeep Jindal
On Mon, Sep 21, 2015 at 7:03 PM, Pradeep Jindal <praddyjindal@gmail.com>
wrote:
> Yes, I was driving so couldn't reply with deetz. Processes not using any
> peers section would die.
> On Sep 21, 2015 6:54 PM, "Willy Tarreau" <w@1wt.eu> wrote:
>
>> On Mon, Sep 21, 2015 at 03:20:14PM +0200, Emeric Brun wrote:
>> > On 09/21/2015 03:03 PM, Willy Tarreau wrote:
>> > > On Mon, Sep 21, 2015 at 06:25:39PM +0530, Pradeep Jindal wrote:
>> > >> I will give you more info in a while. I did some debugging,
>> > >> "peers->sync_task = NULL;" seems to be the culprit here, First,
>> > >> peers->sync_task is being set to NULL and then being deleted & freed
>> which
>> > >> I think would obviously fail. I moved "peers->sync_task = NULL;" to
>> after
>> > >> task_free call in the code below and it works as expected now. Let
>> me know
>> > >> if this makes sense.
>> > >>
>> > >> ==== peers.c ====
>> > >> static struct task *process_peer_sync(struct task * task)
>> > >> {
>> > >> struct peers *peers = (struct peers *)task->context;
>> > >> struct peer *ps;
>> > >> struct shared_table *st;
>> > >>
>> > >> task->expire = TICK_ETERNITY;
>> > >>
>> > >> if (!peers->peers_fe) {
>> > >> /* this one was never started, kill it */
>> > >> signal_unregister_handler(peers->sighandler);
>> > >> peers->sync_task = NULL;
>> > >> task_delete(peers->sync_task);
>> > >> task_free(peers->sync_task);
>> > >> return NULL;
>> > >> }
>> > >> ==== peers.c ====
>> > >
>> > > Absolutely! This is definitely a bug. CCing Emeric who may have an
>> idea
>> > > when this may happen.
>> > >
>> > > Thanks,
>> > > Willy
>> > >
>> >
>> > Yep, it's a bug! I think the issue should happen when a 'peers' section
>> isn't
>> > used by any 'frontend/backend' bound on current process.
>>
>> I confirm. 5 out of 6 processes die with Pradeep's config. Since I didn't
>> know what to look for, I didn't notice.
>>
>> I'm applying your fix, Pradeep. Thanks!
>> Willy
>>
>>
over earlier on both of my haproxy instances. stick table entries are being
synced from A->B but not B->A. I have tried using single process too. Any
idea what could be wrong here?
- Pradeep Jindal
On Mon, Sep 21, 2015 at 7:03 PM, Pradeep Jindal <praddyjindal@gmail.com>
wrote:
> Yes, I was driving so couldn't reply with deetz. Processes not using any
> peers section would die.
> On Sep 21, 2015 6:54 PM, "Willy Tarreau" <w@1wt.eu> wrote:
>
>> On Mon, Sep 21, 2015 at 03:20:14PM +0200, Emeric Brun wrote:
>> > On 09/21/2015 03:03 PM, Willy Tarreau wrote:
>> > > On Mon, Sep 21, 2015 at 06:25:39PM +0530, Pradeep Jindal wrote:
>> > >> I will give you more info in a while. I did some debugging,
>> > >> "peers->sync_task = NULL;" seems to be the culprit here, First,
>> > >> peers->sync_task is being set to NULL and then being deleted & freed
>> which
>> > >> I think would obviously fail. I moved "peers->sync_task = NULL;" to
>> after
>> > >> task_free call in the code below and it works as expected now. Let
>> me know
>> > >> if this makes sense.
>> > >>
>> > >> ==== peers.c ====
>> > >> static struct task *process_peer_sync(struct task * task)
>> > >> {
>> > >> struct peers *peers = (struct peers *)task->context;
>> > >> struct peer *ps;
>> > >> struct shared_table *st;
>> > >>
>> > >> task->expire = TICK_ETERNITY;
>> > >>
>> > >> if (!peers->peers_fe) {
>> > >> /* this one was never started, kill it */
>> > >> signal_unregister_handler(peers->sighandler);
>> > >> peers->sync_task = NULL;
>> > >> task_delete(peers->sync_task);
>> > >> task_free(peers->sync_task);
>> > >> return NULL;
>> > >> }
>> > >> ==== peers.c ====
>> > >
>> > > Absolutely! This is definitely a bug. CCing Emeric who may have an
>> idea
>> > > when this may happen.
>> > >
>> > > Thanks,
>> > > Willy
>> > >
>> >
>> > Yep, it's a bug! I think the issue should happen when a 'peers' section
>> isn't
>> > used by any 'frontend/backend' bound on current process.
>>
>> I confirm. 5 out of 6 processes die with Pradeep's config. Since I didn't
>> know what to look for, I didn't notice.
>>
>> I'm applying your fix, Pradeep. Thanks!
>> Willy
>>
>>