See subtask T3082 for origin and details of this issue.

As discussed in Slack channel, these leftover processes should be cleaned up the next time configuration mode is entered (by UnionfsCstore::setupSession). In my limited testing, I can reproduce the leftover processes as above, but they are cleaned up the next time I enter config mode. There may well be corner cases where this mechanism is not successful, but I have not reproduced.

https://github.com/vyos/vyos-1x/pull/583
https://github.com/vyos/vyos-build/pull/129

set service https certificates certbot

domain-name(s) should contain the desired server-name. A rewrite is in progress in:
https://phabricator.vyos.net/T2289

It exists:
https://phabricator.vyos.net/T1585

This still needs to be integrated into check-qemu-install before PR:
https://github.com/vyos/vyos-1x/compare/current...jestabro:vyos-configtest

Thanks @Viacheslav; I'm running other tests with vyos-load-config at the moment, and will check and add.

Ongoing discussion in the forum on this matter:
https://forum.vyos.io/t/commit-causing-vyos-configd-service-to-exit-and-restart/5945
Summary to follow when there is a reproducer.

@Viacheslav et. al. note that the succinct Mem-Info message shown above was added after v4.19 (commit ef8444ea), so was only seen during the brief window when we moved to 5.8 before reverting the kernel version, due to QAT issues and a bug affecting parted.

@querubin thanks for the info; that requirement should not persist, as current work should lessen the overhead. I'll link the task back here when defined.

@querubin Thank you for the detailed results --- firstly, these issues may be overdetermined due to several updates earlier this month; one notable issue is that we had moved to a 5.x series kernel, which showed several problems re QAT support, and an identified kernel bug. We have reverted to 4.19 as of yesterday until the next LTS kernel is available. I would suggest trying the most recent rolling, and then we will diagnose any persistent issues.

This is resolved by T2332; the normalized form is:

Taking a look ...

@querubin please try booting with the vyos-configd service masked: add the kernel boot parameter:

Resolved in PR536.

@thomas-mangin in further tests, I've seen wide variability in timing tests, independent of caching, with the original quote being the high-end. That will need to be investigated, but I think performance should not be considered a road-block for now.

@tux, this has been fixed in the current rolling.

FRR 7.4 has been released, and the default behaviour has been changed, commit 62282e8379. @Viacheslav, when we update to this version, I can work with you to update the migration script.