Error while upgrading Mastodon: `Uhoh, unknown permission mastodon.main`

Support
1

My YunoHost server

Hardware: VPS bought online
YunoHost version: 11.0.10.2
I have access to my server : Through SSH
Are you in a special context or did you perform some particular tweaking on your YunoHost instance ? : Yes, I’m fresh after updating to yunohost 11

Description of my issue

I was upgrading Mastodon, and the upgrade failed due to some permission issues:

Uhoh, unknown permission mastodon.main ? (Maybe we're in the process or deleting the perm for this app...)

Then Yunohost tried to revert the backup of Mastodon, but it failed, so I ended up with no working Mastodon version.

Here’s the full log: https://paste.yunohost.org/raw/anehewolad

BTW, I seem to be getting this “something is wrong with permissions so yunohost fails disgracefully” sometimes, but I don’t see the problem reported elsewhere. Could there be something that I’m doing wrong that’s causing that to happen? See Failed synapse upgrade for context

2

The actual issue for the failed upgrade is :

2023-01-05 17:36:12,513: DEBUG - + sudo -u mastodon RAILS_ENV=production PATH=/opt/rbenv/versions/mastodon/bin:/opt/node_n/n/versions/node/16/bin:/opt/node_n/bin:/opt/rbenv/shims:/opt/rbenv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so bin/bundle exec rails assets:clean
2023-01-05 17:36:18,615: DEBUG - rails aborted!
2023-01-05 17:36:18,615: DEBUG - LoadError: Could not open library '/var/www/mastodon/live/vendor/bundle/ruby/3.0.0/gems/blurhash-0.1.6/lib/../ext/blurhash/encode.so': /var/www/mastodon/live/vendor/bundle/ruby/3.0.0/gems/blurhash-0.1.6/lib/../ext/blurhash/encode.so: cannot open shared object file: No such file or directory

which I’ve seen elsewhere reported by other people …

Then during the remove-after-failed-upgrade, we see:

2023-01-05 17:36:59,008: DEBUG - [###########++.......] > Removing app main directory...
2023-01-05 17:42:15,091: WARNING - rm: cannot remove '/var/www/mastodon': Device or resource busy

maybe because the service was still running / file used by some program, idk :confused:

and therefore during the restore-after-failed-upgrade it failed because /var/www/mastodon already existed:

2023-01-05 18:00:17,639: DEBUG - 1077018 + test '!' -d /var/www/mastodon
2023-01-05 18:00:17,639: DEBUG - 1077019 + ynh_die '--message=There is already a directory: /var/www/mastodon '
2023-01-05 18:00:17,668: DEBUG - 1077044 + echo 'There is already a directory: /var/www/mastodon '

Soooo that doesnt help much but this seem to have nothing to do with permissions

I think maybe if you manually delete the old /var/www/mastodon, maybe the restoration can work this time

3

The /var/www/mastodon directory is a mount root for an external volume, I can’t delete it. Is it possible to just have yunohost check if it’s an empty dir and proceed? I don’t have enough free space to make yuno install Mastodon on the root filesystem

4

Ugh I see …

I think one workaround would be to mount the external volume as /var/www/ instead of just /var/www/mastodon, but that may imply too many file movement if you have already a bunch of other apps installed

The other way would be to edit the app restore script inside the archive to remove the test ! -d $final_path check :confused:

5

I’m going to remount the /var/www directory as another external volume, move the files there, and see how it goes :+1:

6

This helped. The app was restored. The app didn’t want to start, though. I was getting

/var/www/mastodon/live/vendor/bundle/ruby/2.7.0/gems/ffi-1.10.0/lib/ffi/library.rb:112: [BUG] Segmentation fault at 0x0000000000189dc8
ruby 2.7.2p137 (2020-10-01 revision 5445e04352) [x86_64-linux]

Thanks to this blog post I now fixed this by adding Environment="LD_PRELOAD=libjemalloc.so" to

  • /etc/systemd/system/mastodon-web.service,
  • /etc/systemd/system/mastodon-sidekiq.service and
  • /etc/systemd/system/mastodon-streaming.service

and restarting the mastodon-web, mastodon-streaming and mastodon-sidekiq services.

Also, some .so files within gem directories were missing. I had to go there and run make manually to create those

1 Like
7

This helped me to remove the original files in /var/www from the original partition after the new one has been mounted:

Also, remember to copy the hidden .well-known directory from /var/www, as it’s not caught by the /var/www/* glob!

8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.