Open What-Do-I-Know opened 1 year ago
Can you try these commands manually?
$ ps aux |grep crc
$ launchctl list | grep com.redhat.crc.daemon
$ launchctl stop com.redhat.crc.daemon
$ launchctl load -w /Users/jp/Library/LaunchAgents/com.redhat.crc.daemon.plist
and then check again ps aux
to see if thedaemon is running?
Can you also run ~/.crc/bin/crc daemon --log-level debug
by hand?
Had a similar issue during unrelated testing, crc cleanup && crc setup
helped in my case, I see this was not helpful for you :(
Checked the daemon was not working, then:
launchctl load -w /Users/jp/Library/LaunchAgents/com.redhat.crc.daemon.plist
launchctl list | grep com.redhat.crc.daemon
2829 0 com.redhat.crc.daemon
Then I can crc start
Stopping it and tunning by hand works (I also tested I can crc start
when runnig the daemon manually):
~/.crc/bin/crc daemon --log-level debug
DEBU CRC version: 2.12.0+ea98bb41
DEBU OpenShift version: 4.11.18
DEBU Podman version: 4.2.0
DEBU Running 'crc daemon'
INFO listening /Users/jp/.crc/tap.sock
INFO listening /Users/jp/.crc/crc-http.sock
0B sent to the VM, 0B received from the VM
0B sent to the VM, 0B received from the VM
0B sent to the VM, 0B received from the VM
0B sent to the VM, 0B received from the VM
0B sent to the VM, 0B received from the VM
0B sent to the VM, 0B received from the VM
Question is why the installer fails to start the daemon?
Question is why the installer fails to start the daemon?
It will be hard to retry this now. Perhaps it would be best to describe this as part of a troubleshooting to prevent similar issues for users. Although, a crc cleanup && crc setup
would have been cleaner to peform these steps.
@What-Do-I-Know When it fails as part of crc setup
can you open the console
application and then go to Log Reports
and then select launchd.log , check if you find out some more info around why it is failing as part of setup
but works when you manually load it.
I've been able to reproduce something similar, but no idea if it's the same as your issue.
I had a pop up open on my mac asking me to unlock a keychain, and this apparently is causing issues with starting the daemon through launchctl. The daemon is running but not answering to requests on its socket, crc start
complains with Is 'crc daemon' running? Cannot reach daemon API: Get "http://unix/api/version": dial unix /Users/teuf/.crc/crc-http.sock: connect: connection refused
If I retry crc cleanup && crc setup
, the 'keychain unlock' popup shows again, and starting the daemon through launchctl fails again.
As soon as I closed all the keychain unlock popups, crc start
proceeded as usual.
This started happening with commit 7a5d10aacd6ae441e5000d0a0914fade7d39f6a3
@anjannath
Ahh :( , the "unlock keychain" pop-up comes from this part of the code, when we are initialising the new secret store https://github.com/crc-org/crc/blob/76d07a985c9a7be95beba9b9c796760b6c258817/pkg/crc/config/secret_config.go#L27-L32
It checks if the keychain can be used/accessible early on when initialising the config by trying to store some value, this was added to handle an error on Linux we observed on the linux CI where the gnome secret-service
was not accessible and that resulted in some warning, which is still better as that happens when the crc config set|unset|get
commands are ran but the current situation prevents the daemon for running on macOS when the Login
keychain is locked.
while on a default macOS installation the Login
keychain is unlocked once at login and remains unlocked for the whole session, in your case @cfergeau and also @What-Do-I-Know maybe it gets locked after sometime? and that is the reason the daemon is not able to start.
another reason that @adrianriobo mentioned on slack is if we are accessing via ssh but the GUI login was not done in that case launchd
service does not start or keychain needs to be unlocked manually as the pop-up is only shown when a graphical login session is available.
as a workaround set the following settings (untick the "lock after" or "lock on sleep") for the Login
keychain, open "keychain settings" by right-clicking on the login keychain..
or use the commands below if on ssh:
$ security list-keychains # find out the login keychains path
"/Users/anjan/Library/Keychains/login.keychain-db"
"/Library/Keychains/System.keychain"
$ security unlock-keychain /Users/anjan/Library/Keychains/login.keychain-db
password to unlock /Users/anjan/Library/Keychains/login.keychain-db:
I'll check if keychainAccessible
can be removed or a replacement is needed to make the same check without having to try to store something
@What-Do-I-Know did you try the workaround mentioned in https://github.com/crc-org/crc/issues/3458#issuecomment-1359982769 and does it help? are you running crc setup
from an ssh session?
General information
crc setup
before starting it (Yes/No)? YesCRC version
CRC status
CRC config
Host Operating System
Steps to reproduce
Expected
crc setup completes with success.
Actual
crc setup fails with error: "Temporary error: daemon is not running yet (x8)"
Logs
Before gather the logs try following if that fix your issue
$ crc stetup --log-level debug