Okay, so this problem just got a LOT more bizarre.

The runtime errors are fixed by the above commit.

@kroy I can't really reproduce it if I disable the peer first when multiple peers are defined on the same wg interface.
Can you please do a touch /tmp/vyos.ifconfig.debug and then run your commands and post it here?
It will show you the commands execute for each step like:

vyos@wg01# set  interfaces wireguard wg0 peer wg02 disable 
[edit]
vyos@wg01# commit
[ interfaces wireguard wg0 ]
DEBUG/wg0    write '1420' > '/sys/class/net/wg0/mtu'
DEBUG/wg0    write 'wg0' > '/sys/class/net/wg0/ifalias'
DEBUG/wg0    cmd 'wg set wg0 peer G1aA2KkyFyC8xsCUeENvuIW8HC5yDxwi902nR20592Y= remove'
DEBUG/wg0    cmd 'wg set wg0 listen-port 12345 fwmark 0 private-key /config/auth/wireguard/default/private.key peer hbwJSCu6SGUKIReNhWxlDIFRNCl5L7PaUSYOo2BF+Rg=  preshared-key /dev/null  allowed-ips 10.100.100.3/32 endpoint 10.1.1.203:12345 persistent-keepalive 0'
DEBUG/wg0    cmd 'ip link set dev wg0 up'

https://github.com/vyos/vyos-1x/commit/fde531d3791a3d71aa27f99244d7cbb3b3625bf0

What were the steps you used when you upated the pubkey?

When the config was gone, the processes still seemed to be running

You can via https://github.com/vyos/vyos-1x/commit/dad110ce666edae42ac18c59a800bda503589f27, which just sets the completion help.
For T1845, yes it solves the issue with setting address:port _and_ moves protocol up from facility to host. Do you want me to revert and do 2 commits, which requires then 2 migrations, once for address:port and one to solve the logical issue with protocol. Right now you can set a different protocol for different facilities for the same host.

Wrong logic.
Need to return line 108 code

print (cmd.decode (). split (",", 1) [0])

Bug in latest rolling

Wha cant the change which adds the completion helper be backported? Git best practice is you should group changes per commit. But in this commit you add the completion helper and also other regexes (BAD!)

Will interfere with T1845, while I think T1845 should be the backport candidate. Facility is a tag node, protocol has been moved on level up and is host specific. Having the availability to set different port per facility doesn't really make sense.

It work for 1.2 version (used systemd-shutdownd.service).
For 1.3 some bug with:

PR https://github.com/vyos/vyos-1x/pull/173

That is definately much better then before. But it doe not fix the second problem.

If we replace string 108 in file /usr/libexec/vyos/op_mode/powerctrl.py

Backported

In rolling this was fixed T1204, we need add this to crux.

https://phabricator.vyos.net/T1228 sent the bug and I backported from upstream . The PR is in T1228 but needs to be merged into our package which I don't have permissions for.

as far as i know the content of the platform field is the first characters from sysdescr (20 characters?). on one of my devices this is

System Description:
Cisco IOS Software, C2960 Software (C2960-LANBASEK9-M), Version 15.0(2)SE8, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2015 by Cisco Systems, Inc.
Compiled Thu 14-May-15 02:39 by prod_rel_team

As noone complained that this option is not working (and it is an extension to regular ppp) I propose to remove it.

Thanks, should be backported to crux then as I found it there

https://github.com/vyos/vyos-1x/commit/dad110ce666edae42ac18c59a800bda503589f27

Gotcha, I start implement it for the rolling release for now. Since it affects multiple other nodes as well, I'll do it for all of them equally. aka facility has no constraint and completion help too. There are a few more I've found, so I crawl through all of them and enhance it a bit.

Nope, I was talking about completionHelper, which is not implemented - same as constraint nodes for udp/tcp regex.

@c-po I used the 1.2.3 iso from the download portal and can't reproduce the issue. The help message was also already there since it was (re)implemented, could it be an issue with your installation?

If we cancel reboot, it also write about shutdown.

how can this be invalid and closed? The error is still there on a Crux build of this week...

This is already resolved in upcoming v1.2.4 release. It is due to T1738 and T818

From CPO on Slack:

@kroy AFAIK, intel drivers, KVM (VM performance and I/O), Kernel memory I/O etc.
Performace data can be recorded and replyed asewll. Looks like candidate for debug images as @c-po pointed out.

I guess I'd ask the question of whether we have any complaints of performance type issues that perf could pinpoint? I don't know if I've ever seen any of those kind of complaints in the circles I hang out in.

perf is a tool to gather performance and debug data on a running system with a deep insight into program functions etc. Since it will need a bunch of new libs within the system, I'd like to find out if there is the need for it or not.

I was reading old documentation. It does work once I set it with the configuration instead of editing the file directly.

Added additional check before cycle.