Frontend_startup upgrade does not create monitor group directories
Derek reported this issue specific to the RPM, but it is probably true for the tarball version as well. If you create new groups or change monitor directory, it succeeds reconfig but then fails on run time with the traceback:
2012-07-12T16:14:07-05:00 20605] Exception occurred: ['Traceback (most recent call last):\n', ' File "/usr/sbin/glideinFrontendElement.py", line 838, in iterate\n write_stats(stats)\n', ' File "/usr/sbin/glideinFrontendElement.py", line 48, in write_stats\n stats[k].write_file();\n', ' File "/usr/lib/python2.4/site-packages/glideinFrontendMonitoring.py", line 289, in write_file\n monitoringConfig.write_file("frontend_status.xml",xml_str)\n', ' File "/usr/lib/python2.4/site-packages/glideinFrontendMonitoring.py", line 46, in write_file\n fd=open(fname+".tmp","w")\n', "IOError: [Errno 2] No such file or directory: '/var/lib/gwms-frontend/vofrontend/monitor/group_T2Overflow/frontend_status.xml.tmp'\n"]
I fixed a bunch of these when I made the RPM, so I will investigate and fix this.
#2 Updated by Douglas Strain over 7 years ago
- Status changed from New to Feedback
- Assignee changed from Douglas Strain to Parag Mhashilkar
Hi Parag, could you review this code. It is in branch_v2plus_2824 and covers commits for both this and feature #2825. Basically, it is to handle directories smoother during reconfig/upgrade so that missing/changed directories do not cause unnecessary problems. Now, an "upgrade" will perform most of the tasks of the create_frontend, so that even if a directory is lost, it can be re-created.