On Mon, Mar 22, 2021 at 04:13:26PM -0400, Vivek Goyal wrote: > On Mon, Mar 22, 2021 at 11:00:52AM +0000, Stefan Hajnoczi wrote: > > On Wed, Mar 17, 2021 at 08:32:31PM +0800, Jiachen Zhang wrote: > > > On Wed, Mar 17, 2021 at 6:05 PM Stefan Hajnoczi wrote: > > > > On Fri, Dec 18, 2020 at 05:39:34PM +0800, Jiachen Zhang wrote: > > > I agreed with you that a virtiofsd must be launched by a software like > > > systemd. So we are planning to define more generic persist/restore > > > interfaces (callbacks). Then anyone can implement their own persist/restore > > > callbacks to store states to proper places. And I think in the next > > > version we will implement default callbacks for the interfaces. Instead of > > > vhost-user messages, systemd's sd_notify(3) will be the default method for > > > storing fds, and several tmpfs files can be the default place to store the > > > shm regions. > > > > Okay, great! > > > > I was thinking about how to make the crash recovery mechanism reusable > > as a C library or Rust crate. The mechanism is a combination of: > > 1. sd_listen_fds(3) for restoring the fds on restart. > > 2. sd_notify(3) for storing the fds. > > 3. memfd or tmpfs for storing state (could be mmapped). > > > > I'm not sure if there is enough common behavior to create a reusable API > > or if this is quite application-specific. > > I am wondering what will happen for use cases where virtiofsd is running > inside a container (with no systemd inside containers). > > Do container managers offer systemd like services to save and restore > state. It appears so, at least for Podman where sd_notify is explicitly mentioned: https://www.redhat.com/sysadmin/improved-systemd-podman As mentioned in this email thread, the socket activation and sd_notify(3) interface can also be implemented by non-systemd software. Anyone running a custom container runtime or orchestration software could add these interfaces (they are reasonably simple and the protocols are documented in the systemd documentation). Stefan