If service is 'failed' state

vyos@VyOS-Test01:~$ systemctl status vyos-container-suricata.service
× vyos-container-suricata.service - VyOS Container suricata
     Loaded: loaded (/run/systemd/system/vyos-container-suricata.service; static)
     Active: failed (Result: exit-code) since Fri 2024-08-23 10:32:44 UTC; 43s ago
   Duration: 4min 55.702s
    Process: 2855 ExecStartPre=/bin/rm -f /run/vyos-container-suricata.service.pid /run/vyos-container-suricata.service.cid (code=exited, sta>
    Process: 2856 ExecStart=/usr/bin/podman run --conmon-pidfile /run/vyos-container-suricata.service.pid --cidfile /run/vyos-container-suric>
    Process: 2867 ExecStopPost=/usr/bin/podman rm --ignore -f --cidfile /run/vyos-container-suricata.service.cid (code=exited, status=0/SUCCE>
    Process: 2873 ExecStopPost=/bin/rm -f /run/vyos-container-suricata.service.cid (code=exited, status=0/SUCCESS)
        CPU: 129ms

In T6673#198344, @a.hajiyev wrote:

You are right there is an op-mode command to restart the container

restart container suricata

But I think there needs to be some checks/changes at least someone will execute the native Podman command to restart the container.

You are right there is an op-mode command to restart the container

restart container suricata

But I think there needs to be some checks/changes at least someone will execute the native Podman command to restart the container.

Sorry, but that was my own mistake. When I checked again today, I noticed that the connections were not allowed in the firewall.

It fails because you do it in the wrong way

PR to follow smoketests and cosmetic changes:
https://github.com/vyos/vyos-1x/compare/current...jestabro:configdep-prio

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

vyos@r14:~$ show ntp
.- Number of sample points in measurement set.
                            /    .- Number of residual runs with same sign.
                           |    /    .- Length of measurement set (time).
                           |   |    /      .- Est. clock freq error (ppm).
                           |   |   |      /           .- Est. error in freq.
                           |   |   |     |           /         .- Est. offset.
                           |   |   |     |          |          |   On the -.
                           |   |   |     |          |          |   samples. \
                           |   |   |     |          |          |             |
Name/IP Address            NP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
==============================================================================
ec2-34-206-168-146.compu>  31  15   70m     +0.225      0.056  +1295us   112us
ec2-18-193-41-138.eu-cen>  31  13   70m     -0.305      0.070   -968us   119us
ec2-122-248-201-177.ap-s>   6   3   52m     -2.587      0.901   +109us   252us
vyos@r14:~$

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

Is there any way to incentivize the addition of this?

A workaround doe DHCP client to make it work again: https://github.com/vyos/vyos-1x/pull/4002

A few immediate notes, before preparing the solution:
(1) this is independent of whether one is running under configd or not
(2) this is more easily triggered under 1.4/1.5, which has default ['system', 'conntrack', 'modules'] entries (fixed in current), though can be reproduced in current with the above and 'set ... conntrack modules ..'
(3) this was avoided in 1.4.0 by the global dependency pruning; that raised other serious issues, however (T6559), due to constraints of the legacy commit algorithm.

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

It looks like you are already running this with a high reporting level. Are you seeing any/all the messages on stderr? I would try all of this on the command line first, and do the VyOS cli later.

possible fix

if 'source_interface' in config:
    # my code here
    config['ifname'] = config['source_interface']

The issue is not found in 1.3.8 version but found in 1.4.0 and latest 1.5 rolling release.

@shaneshort this might look like a trivial one but we've already checked it out

Tested in the latest version 1.5-rolling-202408200022, the renaming migration works and the configuration:

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

Yeah I was running lcdproc in a separate window in the foreground as well, and restarted it each time I change a setting in LCDd

I think it has a interesting option `ethtool -K ethX ntuple [on|offwhich is interesting has the knowledge , we can keep it as a part the main task .

Another note—our current RPS implementation intentionally excludes core 0 from packet processing. If we want the default RSS behavior to mimic, this might mean we should be using N-1 queues where N is the number of cores. Whether this makes sense to carry over to RSS I'll leave open for debate.

Should RSS/ntuple be the default or should it be an opt-in "offload" setting?

Ack, I'm inclined to close this as a duplicate. What's the best way to mark the ticket?

I need to reopen the code from the lcdproc project as well as the platform package from Lanner and "compare".

The LCDd exit with code 1 was resolved by simply changing Driver=cwlnx to Driver=CwLnx

I now have an appliance to use for testing. Tried setting the driver to hd44780 and nothing seems to happen. Set ReportLevel to 5 on both lcdproc and LCDd.
On lcdproc the only output is

this task is already created, it involved many offload/NIC tunning which are described on this :

Doesn't cloud-init fully cover this? We are provisioning our VPN endpoints fully via that and thus never need to touch the device once it is running. You need to provide an according config file + .iso at initial boot though, which might only be feasible when VyOS runs inside a VM.