Bus error after snapshot restore

Incus
1

Hi all,

I hope someone has a better solution to this (small) problem.

A bash script with:

  • incus snapshot restore tst snap0
  • incus exec tst – systemctl reload nginx
    returns: Failed to connect to bus

A bash script with:

  • incus snapshot restore tst snap0
  • sleep 10
  • incus exec tst – systemctl reload nginx
    gives no problem

Can I do anything other than “sleep 10” to avoid that bus error?

2

Is this a vm or a container? If it’s a vm, it might not be fully started when you try to use the exec command. 10 seconds doesn’t seem too unreasonable for a vm. Containers however usually start very quickly (but can still take a second or two).

3

Welcome!

When a container is starting up, it takes a bit of time before it is ready. You get figure out the stages with the following. Assuming the container is called mycontainer.

$ incus launch images:debian/12 mycontainer
$ incus exec mycontainer -- systemctl is-system-running
Error: Instance is not running
$ incus exec mycontainer -- systemctl is-system-running
initializing
$ incus exec mycontainer -- systemctl is-system-running
running
$

In general, it’s OK if systemctl is-system-running reports that the system is either running or degraded.

The Failed to connect to bus is likely related to the systemd bus. It is definitely not related to a SIGBUS error.

4

I have run into another problem.
After every reboot, every container has status ‘degraded’.
systemctl --failed gives me:

● e2scrub_reap.service loaded failed failed
Remove Stale Online ext4 Metadata Check Snapshots
● systemd-hostnamed.service loaded failed failed

After a ‘systemctl reset-failed’ (without changing anything), the status is ‘running’.

Is there anything I can do to avoid this?

5

Since these are containers, and the images are stock distribution images, some services are bound to fail.

Does e2scrub_reap.service make sense for containers?

systemd-hostnamed.service should have some more details.

6

You are right, e2scrub_reap.service makes no sense in a (zfs) container.
Systemd-hostnamed.service returned an ‘access denied’. Apparently an apparmor problem with the 6.1 kernel.
I wanted to delete /etc/systemd/system/timers.target.wants/e2scrub_all.timer in the vm, but it was’nt even necessary.
After I installed kernel and zfs from zabbly, all problems disappeared.

1 Like