crc icon indicating copy to clipboard operation
crc copied to clipboard

[Spike] Spawn crc daemon on-demand

Open cfergeau opened this issue 4 years ago • 10 comments
trafficstars

See https://github.com/code-ready/crc/issues/2454

This could be solved by having crc start the daemon automatically when needed, and the daemon shuts down automatically after a few minutes idle.

There are at least 2 ways of doing this, either crc takes care of the spawning/process monitoring/..., or we try to take advantage of preexisting OS facilities (systemd user services, launchd user daemons or agents, both need socket/on demand activationo).

cfergeau avatar Jun 21 '21 09:06 cfergeau

We need daemon to be running when a user tries to access any app routes deployed on the crc cluster, when the the daemon exits after some time am afraid these routes would also stop working? or socket activation would take care of this?

anjannath avatar Jun 21 '21 10:06 anjannath

The daemon could keep running as long as the cluster is running, which would avoid this issue. It's when crc is not in use that I prefer the daemon not to be running, and thus to automatically exit when the cluster does not run.

cfergeau avatar Jun 21 '21 12:06 cfergeau

and thus to automatically exit when the cluster does not run.

Will the daemon therefore continuously perform status requests to the VM driver?

Because if the VM is not running, I would not like to see a failing tray (as it can't request the status; daemon stopped).

gbraad avatar Jun 23 '21 11:06 gbraad

Will the daemon therefore continuously perform status requests to the VM driver?

This really is a long term goal, so no idea about this :) My feeling is that the daemon would store some cluster state, but would also monitor that the VM does not unexpectedly disappear.

Because if the VM is not running, I would not like to see a failing tray (as it can't request the status; daemon stopped).

The tray running may be one of the cases when the daemon has to be running, I don't know. But "starting the daemon on demand" implies that if the tray requests status from the daemon, then the daemon will be started automatically if it's not running yet.

cfergeau avatar Jun 23 '21 11:06 cfergeau

then the daemon will be started automatically if it's not running yet.

So this enhancement will not resolve the issue by itself ... so the lifecycle management needs to be handled in different places.

This could be solved by having crc start the daemon automatically when needed,

It is good to understand who needs the daemon to determine who starts what on-demand. While 'socket activation' is helpful, we first need to understand the needs

  • crc needs the daemon for networking
  • tray-windows and tray-macos need the daemon for status requests and starting crc'
  • admin-helper receives calls from the daemon to setup DNS records (which have no need to run either without the VM/Daemon)

especially as not all platforms provide this functionality.

gbraad avatar Jun 23 '21 11:06 gbraad

crc needs the daemon for networking

The way (maybe inaccurate) I see this is that it is the VM started by crc which needs the daemon for networking (and crc needs it for interacting with the VM).

admin-helper receives calls from the daemon to setup DNS records (which have no need to run either without the VM/Daemon)

This one is Windows-specific, on the other platforms admin-helper is a suid executable which is run when needed. I've been focusing on linux and to a lesser extent on macOS, so not much thought given to admin-helper (or Windows in general).

cfergeau avatar Jun 28 '21 17:06 cfergeau

2 ways of solving this that I considered:

  1. add "if !daemonIsRunning() { startDaemon() }tocrc`, but then this means we need to monitor the daemon, makes sure it does not die, be able to stop it when needed, ... all of which can be slightly tricky, and probably platform-dependant. This also means we need to have this code written in go but also in .net and swift for the trays.
  2. use OS-specific services, on linux systemd provides a way to automatically start daemons through socket activation ( https://vincent.bernat.ch/en/blog/2018-systemd-golang-socket-activation ), and launchd on macos provide the same facility as far as I can tell (see SockPathName in https://www.unix.com/man-page/OSX/5/launchd.plist/ and https://github.com/x13a/go-launch/blob/master/launch.go ). Not sure how this would be achieved on Windows though...

cfergeau avatar Jul 09 '21 11:07 cfergeau

linux side of things is tracked in https://github.com/code-ready/crc/issues/2556 and macos in https://github.com/code-ready/crc/issues/2557

cfergeau avatar Jul 09 '21 11:07 cfergeau

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

stale[bot] avatar Sep 08 '21 05:09 stale[bot]

Linux is done, the other platforms are still not taken care of.

cfergeau avatar Nov 30 '21 08:11 cfergeau