GitLab: Your changes could not be commited, because the file has been changed

Not long ago I've migrated last of my SVN-managed projects into Git with GitLab (finally!). Everything was OK, until this message occurred, when I tried to do an web-based repository file update:

Your changes could not be commited, because the file has been changed

After googling I've executed following command (because I didn't create satellites earlier):

sudo -u git -H bundle exec rake gitlab:satellites:create RAILS_ENV=production

Unfortunately this didn't solve my problem (although I'm pretty sure, that either way this was required). I've decided to check GitLab logs, but unluckily nothing suspicious was there. I suddenly remembered, that by default all my Rails/Rack Passenger applications are executed using www-data user. This was a good guess. I've added a user declaration in Apache vhost configuration file:

PassengerUser git

and after that I've finally started to get some new things in application log:

Errno::EACCES (Permission denied - /home/git/gitlab/tmp/satellite_15.lock):
  lib/gitlab/satellite/satellite.rb:57:in `initialize'
  lib/gitlab/satellite/satellite.rb:57:in `open'
  lib/gitlab/satellite/satellite.rb:57:in `lock'
  lib/gitlab/satellite/action.rb:23:in `block in in_locked_and_timed_satellite'
  lib/gitlab/satellite/action.rb:22:in `in_locked_and_timed_satellite'
  lib/gitlab/satellite/edit_file_action.rb:22:in `commit!'
  app/controllers/edit_tree_controller.rb:18:in `update'

All my satellite locks were created by www-data user with different set of privileges, so git user was not able to use them. After I removed all the locks and restarted both GitLab and Apache server, everything started to work just fine:

sudo rm /home/gitlab/tmp/satellite_*
/etc/init.d/apache2 restart
/etc/init.d/gitlab restart

Categories: Hosting, Linux, Rails, Ruby, Software

2 Comments

  1. Actually, Phusion Passenger normally starts your app as the owner of config.ru, or “nobody” if the file is owned by root. The exact behavior is described here: http://www.modrails.com/documentation/Users%20guide%20Apache.html#user_switching

  2. Yes that’s true unless you overwrite it in (for example) apache2.conf with PassengerUser and that’s what I did, so I had one general user to run all the Passenger instances and that’s what made it wrong in the first place (although the fix stays the same)

Leave a Reply

Your email address will not be published. Required fields are marked *

*

Copyright © 2024 Closer to Code

Theme by Anders NorenUp ↑