[BUG] Daemon not properly initialized after crc setup

[adrianriobo]

The daemon process on macos is started from the tray process. The tray is installed before extracting and uncompressing the bundle, so when this long process happens during the setup the daemon is properly initialized.

When we start crc on a previous environment, and all the commands are included on a script (no delay between setup without require bundle management) the setup ends up successfully but the daemon is not properly initialized, and the start ends up failing.

In this case the setup probably should check the state of the daemon to ack that your system is ready to start crc.

Notice that in this case skipping the update check on the start will produce the error, with the check in place the delay is enough for the daemon.

To reproduce:

1. Create a pre existing environment

2. Create a script

crc cleanup
crc setup
CRC_DISABLE_UPDATE_CHECK=true crc start -p PULL_SECRET  --log-level debug

3. Run the script

Logs from previous script

INFO Unload CodeReady Containers tray             
INFO Removing launchd configuration for tray      
INFO Removing /etc/resolver/testing file          
INFO Unload CodeReady Containers daemon           
INFO Stopping CRC Hyperkit process                
INFO Removing hosts file records added by CRC     
INFO Removing pull secret from the keyring        
INFO Removing older logs                          
INFO Removing CRC Machine Instance directory      
Cleanup finished
INFO Checking if running as non-root              
INFO Checking if crc-admin-helper executable is cached 
INFO Checking for obsolete admin-helper executable 
INFO Checking if running on a supported CPU architecture 
INFO Checking minimum RAM requirements            
INFO Checking if running emulated on a M1 CPU     
INFO Checking if HyperKit is installed            
INFO Checking if qcow-tool is installed           
INFO Checking if crc-driver-hyperkit is installed 
INFO Checking if CodeReady Containers daemon is running 
INFO Checking if launchd configuration for tray exists 
INFO Creating launchd configuration for tray      
INFO Check if CodeReady Containers tray is running 
INFO Checking if CRC bundle is extracted in '$HOME/.crc' 
INFO Checking if /Applications/CodeReady Containers.app/Contents/Resources/crc_hyperkit_4.8.4.crcbundle exists 
Your system is correctly setup for using CodeReady Containers, you can now run 'crc start' to start the OpenShift cluster
DEBU CodeReady Containers version: 1.31.2+19538dab 
DEBU OpenShift version: 4.8.4 (not embedded in executable) 
DEBU Running 'crc start'                          
DEBU Total memory of system is 34359738368 bytes  
Is '/Applications/CodeReady Containers.app' running? Cannot reach daemon API: Get "http://unix/api/version": dial unix /Users/crcqe/.crc/crc-http.sock: connect: connection refused

[praveenkumar]

@adrianriobo does it eventually come up or never come up?

[adrianriobo]

@praveenkumar come up? what do you mean? crc start exit on error...then if you start again it works, even if you do it manually it work.... as long as you somehow introduce a bit delay to allow daemon to be ready it will work

[guillaumerose]

Should we add a polling loop in crc setup or should this be only in tests?

[adrianriobo]

crc setup does not warrant the valid state of the daemon... , I hit this on tests but you can mimic with a sample bash script to automate crc setup and crc start which I guess it could be a common use case

[praveenkumar]

As you said in the issue if you have CRC_DISABLE_UPDATE_CHECK to false which default is then it provide enough time for daemon to run so even user do scripting they are not hit this issue until they also disable the update check. Otherwise during the setup we have to make sure if daemon is running by polling it and wait util it is up.

[adrianriobo]

make sure if daemon is running by polling it and wait util it is up

Setup claims your system is ready to start crc which is not true as you are not ensuring this condition?

[adrianriobo]

Fixed by #2722

[adrianriobo]

/close

[openshift-ci]

@adrianriobo: Closing this issue.

In response to this:

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.