Discourse-narrative-bot cannot remove: Permission denied

unsupported-install

(Pat David) #1

Updating this morning I ran into this problem hanging my restart:

May 30 10:36:28 discuss systemd[1]: Started Discourse Sidekiq.
May 30 10:36:30 discuss bundle[9478]: rm: cannot remove '/srv/www/vhosts/discourse/public/plugins/discourse-narrative-bot': Permission denied
May 30 10:36:30 discuss bundle[9478]: /srv/www/vhosts/discourse/lib/discourse.rb:26:in `execute_command'
May 30 10:36:30 discuss bundle[9478]: /srv/www/vhosts/discourse/lib/plugin/instance.rb:367:in `activate!'
May 30 10:36:30 discuss bundle[9478]: /srv/www/vhosts/discourse/lib/discourse.rb:126:in `block in activate_plugins!'
May 30 10:36:30 discuss bundle[9478]: /srv/www/vhosts/discourse/lib/discourse.rb:123:in `each'
May 30 10:36:30 discuss bundle[9478]: /srv/www/vhosts/discourse/lib/discourse.rb:123:in `activate_plugins!'
May 30 10:36:30 discuss bundle[9478]: /srv/www/vhosts/discourse/config/application.rb:179:in `<class:Application>'
May 30 10:36:30 discuss bundle[9478]: /srv/www/vhosts/discourse/config/application.rb:27:in `<module:Discourse>'
May 30 10:36:30 discuss bundle[9478]: /srv/www/vhosts/discourse/config/application.rb:26:in `<top (required)>'
May 30 10:36:30 discuss bundle[9478]: /srv/www/vhosts/discourse/vendor/bundle/ruby/2.3.0/gems/sidekiq-4.2.4/lib/sidekiq/cli.rb:234:in `require'
May 30 10:36:30 discuss bundle[9478]: /srv/www/vhosts/discourse/vendor/bundle/ruby/2.3.0/gems/sidekiq-4.2.4/lib/sidekiq/cli.rb:234:in `boot_system'
May 30 10:36:30 discuss bundle[9478]: /srv/www/vhosts/discourse/vendor/bundle/ruby/2.3.0/gems/sidekiq-4.2.4/lib/sidekiq/cli.rb:50:in `run'
May 30 10:36:30 discuss bundle[9478]: /srv/www/vhosts/discourse/vendor/bundle/ruby/2.3.0/gems/sidekiq-4.2.4/bin/sidekiq:12:in `<top (required)>'
May 30 10:36:30 discuss bundle[9478]: /srv/www/vhosts/discourse/vendor/bundle/ruby/2.3.0/bin/sidekiq:23:in `load'
May 30 10:36:30 discuss bundle[9478]: /srv/www/vhosts/discourse/vendor/bundle/ruby/2.3.0/bin/sidekiq:23:in `<main>'
May 30 10:36:30 discuss systemd[1]: discourse-sidekiq.service: Main process exited, code=exited, status=1/FAILURE
May 30 10:36:30 discuss systemd[1]: discourse-sidekiq.service: Unit entered failed state.
May 30 10:36:30 discuss systemd[1]: discourse-sidekiq.service: Failed with result 'exit-code'.
May 30 10:36:31 discuss systemd[1]: discourse-sidekiq.service: Service hold-off time over, scheduling restart.
May 30 10:36:31 discuss systemd[1]: Stopped Discourse Sidekiq.

It appears that the plugin tries to delete public/plugins/discourse-narrative-bot on every start? Is this expected behavior?


(Christoph) #2

Is this perhaps related to this:


(Sam Saffron) #3

You are going to need to comment out the narrative bot from your app.yml and run a ./launcher rebuild app


(Darix) #4

we are not using docker to run our discourse instance. currently it runs directly from a git checkout but will be moved to a new host using my package. Afaik nobody turned on the plugin.

I dont think the behavior shown by the bot is good. In both cases we try to keep permissions tight. we run the whole asset pipeline as root (script here) and the discourse user, under which the app runs, has only minimal write permissions. IMHO if plugins should create/change symlinks like the narrative bot plugin does, it should happen as part of the asset pipeline code not during every start of the app (puma or sidekiq).


(Sam Saffron) #5

Well this is the way static assets in plugins have worked for a very very long time.

The behavior is nothing to do with the bot, if ANY plugin ships with a /public directory, plugin activation symlinks it so NGINX does not have to go via Rails to get at the assets.

I am not against refining this long term but you have going now is unsupported.