The com.canonical.multipassd service is constantly logging errors on my Mac and multipass won't work at all, even after reinstalling, rebooting, and updating my Mac.
In an attempt to use my GPU in a Linux VM through multipass, I tried to install the AMDGPU driver for my card (Radeon Pro 5300 4GB). I had installed multipass through brew and made some progress, but the ./amdgpu-install process was returning various errors as a result of missing dependencies. Having started to resolve the missing dependencies, in an attempt to build the driver again, the build just stopped halfway through and I couldn't terminate the process or get the VM to respond at all (didn't take a screenshot sorry).
Because of this, I closed the VM shell and tried to get multipass to shut down the VM. Multipass stopped responding altogether - the application just spun, and it didn't respond at all in terminal. I force quit multipass in Activity Monitor. That still didn't fix it, so I (somewhat stupidly) force quit 'hyperkit' and 'multipassd'. This is where everything went really wrong.
Having force quit 'multipassd', I tried to re-open multipass, but it returned the error below
list failed: cannot connect to the multipass socket
Please ensure multipassd is running and '/var/run/multipass_socket' is accessible
I looked this up and tried a few suggested solutions. I uninstalled multipass with Brew. I deleted the application, and reinstalled with brew. I also tried brew remove multipass, and tried installing using the .pkg from the multipass website. When that didn't fix it, I restarted my computer and reset NVRAM on startup. That also didn't make a difference, so I have just updated my Mac to MacOS 11.4, and it is still not fixed.
The console logs suggest that multipassd is still doing something, as it is continually logging in the system.log:
May 26 09:39:15 <myName> com.apple.xpc.launchd[1] (com.canonical.multipassd[2131]): Service exited with abnormal code: 1
May 26 09:39:15 <myName> com.apple.xpc.launchd[1] (com.canonical.multipassd): Service only ran for 0 seconds. Pushing respawn out by 10 seconds.
In the multipass log, this message is also being generated about once every 10 seconds:
[error] [daemon] Caught an unhandled exception: Invalid MAC address
[warning] [Qt] QMutex: destroying locked mutex
These messages are being generated even after resetting NVRAM and rebooting. I think they're the cause of my issue launching multipass, but I haven't found any solution to stop them, and I can't identify any process that is still running related to multipass. As far as brew is concerned, multipass is not installed, but it's logs are still filling up...
Happy to provide console or terminal output if needed - nothing else on my Mac seems to be broken, I just can't use multipass now. I do have a time machine backup, so if that is guaranteed to fix it, I might just resort to the backup, but I'm not sure that would necessarily fix it, and I would rather find an alternative solution.
As this has probably made clear, I'm very new to Linux and VMs... any solutions greatly appreciated!
Fixed it!! I hadn't properly uninstalled it - the 'proper' uninstall script can be run using
sudo sh "/Library/Application Support/com.canonical.multipass/uninstall.sh"
Reinstalling multipass after running this command worked fine.
Related
Similar to the issue #37033541, my commands do not stop. However, my system does not have unmounted drives; my GOPATH is set to /users/user_name/go:/users/user_name/goCode. Neither changing this path to the installation default, nor restarting the computer, or even starting a shell without my bashrc change the behaviour. While it is running, it does generate a functional executable.
I am running go 1.14.1 installed according to the instructions for macOS Mohave.
This behaviour replicates across other packages in my system. But transferring the code to the Go Playground or another Mac computer does not replicate the behaviour. When I run go build -x ..., the last action is: rm -r $WORK/b001/.
Running a stack trace on the process yields ongoing system calls that I cannot interpret (They do seem varied and would be happy to post some if someone would think them useful).
This did not use to happen, it started a few hours ago. I would appreciate the help of someone in troubleshooting this issue.
The issue was resolved only by putting in a fresh installation of the OS and then reinstalling go 1.14.1.
More here: https://groups.google.com/forum/#!topic/golang-nuts/YxqX9o2YJ4k
I am trying to solve a cascading series of bugs that started with me not able to copy to my macOS clipboard from remote ssh and has lead me to realize my X11 situation is seriously messed up. I have read a few other stackoverflow threads and they do not address my particular problems.
First my setup is macOS Mojave 10.14.5. I have xquartz 2.7.11 installed from the website. When I run echo $DISPLAY locally (on macOS) I get /private/tmp/com.apple.launchd.waagOnO6Qm/org.macosforge.xquartz:0.
Since I don't know where the error actually is I will list two problems I can identify currently.
Two problems:
If I run xclock locally nothing happens inside my terminal. I do notice that an "active" dot appears under the XQuartz dock icon for a second and then disappears. But after this happens my terminal still just hangs at xclock as though it is running.
If I try to ssh -X remote into a remote machine my terminal is locked out. I cannot keyboard interrupt. I ran this with -vvv to try to debug and I see that it hangs with xauth:
debug2: client_x11_get_proto: /opt/X11/bin/xauth -f /var/folders/jw/ltyk9x9n0_xb61jhdnct27fr0000gn/T//ssh-vcqwT7qh5yk2/xauthfile generate /private/tmp/com.apple.launchd.waagOnO6Qm/org.macosforge.xquartz:0 MIT-MAGIC-COOKIE-1 untrusted timeout 1260 2>/dev/null
Attempts to Solve
Other related stack threads have suggested reinstalling XQuartz, which I have done, both manually and with Homebrew. I have logged back out and in following reinstallation.
This thread suggested I solve my xauth problem by deleting .XAuthority file and recreating it. However, when I
xauth generate :0 . trusted
My XQuartz pops up a window saying XQuartz quit unexpectedly which I can provide the Report for if it helps. Then in the terminal it says
xauth: (argv):1: unable to open display ":0". Also I'm not sure this is the problem anyway because my .XAuthority file already contained an entry that it looks like this is trying to produce:
$HOST/unix:0 MIT-MAGIC-COOKIE-1 db7738324ca3662767b20b97b4a68680
Though it is concerning that running xauth is causing my xquartz to repeatedly quit unexpectedly (this dialog box is appearing multiple times).
This has been very frustrating to debug because I am not sure where the problem is, with xauth or xquartz somehow even though it is newly installed. Further, existing StackOverflow threads I have found detail the problem only with ssh -X but clearly I'm having problems locally, given that I can't even run xclock.
Any help is greatly appreciated.
The dot appearing and disappearing quickly indicates that the server process is terminating. This means that either the server crashed, the managing client (eg ~/.xinitrc) terminated, or we failed to even start xinit.
Almost every case I have ever seen of this has been due to someone doing something wrong in their init scripts (eg: ~/.bash*, ~/.profile, ~/.xinitrc).
Remove those and try again, then bisect to figure out the underlying issue.
However, the crash dialog from your "ssh" case indicates that it is likely the server crashing. You will need to look at the crash log for more information (or provide it here if you want help with that).
Yesterday evening I closed my macbook's lid and left work. Came back this morning, turned my computer on, and upon trying to log into psql got a warning that the postgres role didn't exist... Upon further inspection, it seems that all but one of my databases are gone (and the default template0/1, postgres and my user's), as well as every roles but mine (<user>). \du+ in the psql console confirms my user has superuser rights. I still tried $ psql -d database_that_disappeared, to no avail. Tried switching to the other postgres versions I have installed locally (9.5.3 --> 9.6.2 --> 9.5.3), with no luck.
I obviously haven't run any brew update or upgrade, nor has OSX automatically updated anything, as I've turned automatic updates off. I have tried both shutting down and rebooting, to no avail either.
Edit: /usr/local/var/postgres/base shows 26 folders + pgsql_tmp, which makes me feel that the data itself isn't gone?
Just to let you know.
I was facing the very same problem.
Realised I had a process called "Google" that was listening to the port 5432 (found out using the command:
lsof -i -n -P | grep 5432
Besides that, my user (in the OS) disappeared as well!
Well, I found out the problem was that I did have two instances of PostgreSQL installed. When my mac restarted for an update, it started automatically the wrong one!
That looks to have happened due to updating the PGAdmin3 to 4. The 4th installs a new version of the PostgreSQL with it and, instead of replacing the previous version (as I expected) it kept both side by side.
Again, this is what I THINK has happened, because I realised I'm suddenly using a previous version of PGAdmin, with the newest version of Postgres (it even triggers a warning message saying there is a version mismatch).
I hope this has helped someone :)
And if you figure out WHY/HOW that happened, let me know.
When there are problems while running a recipe and the client run is hanging half way, the installed Chef client will be unusable.
You can then exit the machine, reboot, clean up chef pid files and so forth but each time the Chef client is started the following message is shown:
Chef client is running, will wait for it to finish and then run.
Chef should be able to recover from this when a reboot is performed but this is not the case.
What is the best way to recover from a client run that hangs half way? Currently I delete the VM and create a new one but that is not a real solution.
Is it possible to recover when it hangs half way?
Stop the service if any running : sudo service chef-client stop
if the issue persists
find out if nay chef client process/service is running: ps aux | grep chef
kill the process
if the issue persists
look up your chef client settings under /etc/chef/client.rb and/or your etc/init.d/chef-client
then locate the pid_file and lockfile path
delete the files
if the issues persists, you might run like me a old version of chef-client
you need to look in your chef cache folder
I had to delete /var/chef/cache/chef-client-running.pid
If it timeout takes place - converging should work fine over and over again. Well, if you need to remove client - you can run sudo rm -rf /etc/chef on client machine. All the options are described here in details.
I ran into the same issue where the kitchen converge process would get hung, typically due to an improper msi installation in my case. I would then have to reboot the kitchen machine.
I noticed that an elevated scheduled task was running which when stopping, it would kill the process, but the issue returned when I ran it again ("chef client 2092 is running, will wait for it to finish and then run").
It then occurred to me that the last attempt to reboot, which normally resolves the issue, didn't succeed because of an open file preventing the reboot. Rebooting the machine did resolve the issue in my case. It's not a perfect solution but it does work as a work-around in my case.
I have an issue when attempting to use postgresql along with homebrew. After doing a completely clean install (and after upgrading from postgresql 9.1.3 to 9.2.4 and doing a system update of MacOS X) it appears that the postgresql that comes with Lion is conflicting with the one that homebrew provides.
The conflict means that when OSX launches (and with the ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist), postgresql fails to load properly at startup, which then causes the
psql: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
error. The thing is, if I then manually load and unload the homebrew.mxcl.postgresql.plist agent, postgresql works from this point onwards, does anyone know how to fix this issue (I think it may be a conflict between /usr/bin/psql and the homebrew's /usr/local/bin/psql)
EDIT: after a fresh reboot and running launchctl list | grep postgres, I get this as a result 680 - homebrew.mxcl.postgresql, running launchctl list | grep pg gives nothing, and for some odd reason, it happens to be working now (even though I havn't changed anything after posting this). Will reboot a few more times to figure out what happened
EDIT2: It actually seems to work now, I have no idea why (wasted like 3 hours on it last night), I am going to mark this as answered until it comes back again
It seems like it was actually working, maybe something odd was happening in the boot sequence but postgres is now working fine, as expected, through homebrew