I also notice looking at the backup after another reboot:
- All Stories
- Advanced Search
- Transaction Logs
Sep 1 2022
I hate to drag up an old ticket, but I've just encountered this issue.
A freshly built VyOS 1.3-rolling-202209010158
Aug 20 2022
I can confirm this has been the reason I've had issues upgrading from 1.2.x to 1.3.x.
Removing this statement before attempting, I can now upgrade from 1.2 to 1.3 smoothly, no OOM errors or other problems.
Nov 16 2021
Mar 21 2021
This is still an issue with 1.2.7-epa1
Mar 17 2021
This is still a problem, I have just upgraded from 1.2.6-S1 to 1.2.7-epa1 and had two conntrackd's running on the primary router.
This is now fixed in 1.2.7-epa1
So I have found a workaround/fix for this.
Mar 11 2021
Same issue. I'm happy to send my config file (not publically) for further debug if that'll help?
Sure thing, I'll try it again tomorrow.
Mar 10 2021
Is there anything else I can do to help debug this issue?
Feb 27 2021
Nov 20 2020
I just saw the patch above for how to fix this and yes, with that line changed to sudo it now works correctly.
Nov 4 2020
Oct 14 2020
Oct 1 2020
Sep 23 2020
Additionally, it only happens after a system image upgrade - it doesn't seem to happen if you reboot again after that.
So I just hit this bug again upgrading from 1.2.6-epa1 to 1.2.6.
Aug 28 2020
Aug 19 2020
So I fixed this on my setup by kill -9 conntrackd
and then sudo /etc/init.d/conntrackd start
Aug 15 2020
Jun 17 2020
Hmmm is it the fact I have a remote syslog configured that triggers this bug?
I didn't realise that, I'll have to remove it and see if it helps.
It's very frustrating not having the firewall logs available to view.
For what little to no weight my opinion matters, I also agree that this should be backported to Crux.
As I've bashed my head into it testing :-)
Jun 8 2020
Apr 24 2020
@jjakob No, it's not logged in the journal either:
Apr 16 2020
Some other people reporting similar here.
Apr 15 2020
I'm seeing this in Vyos 1.2.5 just released:
I've just encountered this bug with Vyos 1.2.5 (final, official ISO)
Apr 14 2020
Apr 13 2020
Apr 9 2020
It would appear this commit is the source of the problem - client-config-dir was removed but I don't see anywhere it's re-added.
Thank you @c-po - I can confirm removal of connect-on-demand fixes the problem.
I was under the, obviously mistaken, impression that I needed that command for PPPoE to self-establish on reboot. But I obviously don't as I've just rebooted with the latest 1.3-rolling-202004090909 and it's connected straight away and is working.
Apr 8 2020
Please find below, with some comments redacted.
The only major differences I've noticed are the kernel versions: