Task #11700
closed
DataMiner - check svn status on Production
Added by Giancarlo Panichi about 7 years ago.
Updated about 7 years ago.
Infrastructure:
Production
Description
I noticed that the DataMiner service in production are not updating the algorithms.
It looks like there are problems with svn update:
gcube@dataminer2-p-d4s:~/wps_algorithms/algorithms/prod$ svn update
svn: E155004: Run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
svn: E155004: Working copy '/home/gcube/wps_algorithms/algorithms/prod' locked.
svn: E155004: '/home/gcube/wps_algorithms/algorithms/prod' is already locked.
this should resolve with a:
svn cleanup
on all services as root.
Please, can you check the status of these DataMiner.
Thanks
Files
- Status changed from New to Closed
- % Done changed from 0 to 100
Someone operated the svn repository as root - again - on that dataminer:
ls -la /home/gcube/wps_algorithms/algorithms/prod/.svn/pristine/8f/8ff54281eb2a58fbb66db4c09b9da7efc51dcd3a.svn-base
-rw-r--r-- 1 root root 100416 Apr 5 15:05 /home/gcube/wps_algorithms/algorithms/prod/.svn/pristine/8f/8ff54281eb2a58fbb66db4c09b9da7efc51dcd3a.svn-base
And I'm really pissed off by this behaviour, not that anybody minds.
The /home/gcube/wps_algorithms_install_log/algorithms_updater_cron.log contains the details:
$ cat /home/gcube/wps_algorithms_install_log/algorithms_updater_cron.log
svn: E000013: Can't remove file '/home/gcube/wps_algorithms/algorithms/prod/.svn/pristine/8f/8ff54281eb2a58fbb66db4c09b9da7efc51dcd3a.svn-base': Permission denied
svn: E155004: Run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
svn: E155004: Working copy '/home/gcube/wps_algorithms/algorithms/prod' locked.
svn: E155004: '/home/gcube/wps_algorithms/algorithms/prod' is already locked.
The file with suffix .svn-base must be manually removed, as root, to fix the procedure. Every error other than an algorithm installation failure is reported in that file, on every dataminer instance.
I have made a check and it seems that this error is present on many production machines always with the same date.
So, I have the doubt that it is not just a human error.
In the file some machines I tested.
The provisioning of that part always happens as gcube user. The relevant tasks are:
- block:
- name: Install the subversion packages
become_user: root
apt: pkg=subversion state=present update_cache=yes cache_valid_time=1800
- name: Create a directory where to install the algorithms directory
file: path={{ smartgears_user_home }}/wps_algorithms/algorithms state=directory
tags: [ 'tomcat', 'dataminer', 'wps', 'dataminer_algorithms', 'dataminer_algorithms_svn' ]
- name: Download the WPS algorithms from subversion
subversion: repo={{ dataminer_wps_algorithms_svn }} dest={{ smartgears_user_home }}/wps_algorithms/algorithms/{{ dataminer_infra_reference }} checkout=yes force=yes update=yes
tags: [ 'tomcat', 'dataminer', 'wps', 'dataminer_algorithms', 'dataminer_algorithms_svn' ]
become: True
become_user: '{{ smartgears_user }}'
tags: [ 'tomcat', 'dataminer', 'wps', 'dataminer_algorithms', 'dataminer_algorithms_installer' ]
In no way that damage could have been done by the provisioning.
- Status changed from In Progress to Closed
- % Done changed from 60 to 100
I forced a chown -R gcube:gcube /home/gcube/wps_algorithms/algorithms on all the production dataminers.
Also available in: Atom
PDF
Updated by 
Updated by 
