Task #11700
closed
DataMiner - check svn status on Production
100%
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
Updated by Andrea Dell'Amico about 7 years ago
- 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.
Updated by Giancarlo Panichi about 7 years ago
- File DataMinerProdError.xlsx DataMinerProdError.xlsx added
- Status changed from Closed to In Progress
- % Done changed from 100 to 60
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.
Updated by Andrea Dell'Amico about 7 years ago
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.
Updated by Andrea Dell'Amico about 7 years ago
- 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.
