Closed zhongcloudtian closed 1 month ago
@rodnymolina help me
@zhongcloudtian, the most common scenario in which you would see this error that you're referring to (function not implemented
) is when one of the Sysbox daemons (either sysbox-fs
or sysbox-mgr
) is restarted, AND pre-existing Sysbox-powered containers/pods have kept on operating.
In other words, if sysbox daemons are restarted for whatever reason (either a manual restart or because of a sysbox bug that caused a crash/restart), then any pre-existing containers/pods launched through Sysbox must be restarted too.
During container initialization, sysbox-fs
injects a special file-descriptor into the container operational environment. This file-descriptor is used to trap certain syscalls that are required for Sysbox's proper operation (i.e., only mount()
and umount()
syscall these days). This communication channel between containers/pods and Sysbox is disrupted the moment that sysbox-fs
is restarted, so that's why you're probably seeing that error log above since the pre-existing pods are not aware of this incident; thereby, they must be manually restarted.
To confirm my point above do this:
1) Verify that Sysbox has been restarted by looking at your systemd logs with sudo journalctl -u sysbox-mgr -u sysbox-fs
.
2) Delete and re-create the pods; you shouldn't see any issue with new instantiations of your pods.
Echoing @rodnymolina comment, the function not implemented
error occurs when the sysbox-fs
daemon is down / not-responding for some reason. So the sysbox-fs logs would really help.
sysbox-fs - panic: runtime error: index out of range [0] with length 0 issuse #633 --allow-trusted-xattr=false
Thanks @zhongcloudtian.
I was not able to repro, however the panic should be fixed by this PR, which will be present in the upcoming release.
Thanks!
Closing as duplicate of #633 .