Hello, I was just trying to apply this tweak to the gridftpdoors on
the lancaster dcache srm pool nodes:
https://wiki.gridpp.ac.uk/wiki/DCache_FAQ#How_do_I_record_the_DN_of_a_user_who_is_uploading_files.3F
The procedure is nice and simple, and requires a restart of the
dcache-opt services. On some of my pool nodes something strange has
happened, the dcache-opt service (more specifically the gridftp door)
will not die when the script tells it to, thus preventing the
dcache-opt service from opening a new door:
[root@fal-pygrid-26 root]# /opt/d-cache/bin/dcache-opt restart
Shutting down dcache doors Stopping gridftpdoor-fal-pygrid-26Domain
(pid=32059) 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Giving up : gridftpdoor-fal-pygrid-26Domain might still be running
No GsidCap door to stop
No SRM door to stop
Starting dcache doors gridftpdoor-fal-pygrid-26Domain might still be running
No GsidCap door to start
No SRM door to start
[root@fal-pygrid-26 root]# ps -p 32059
PID TTY TIME CMD
32059 ? 00:04:22 java <defunct>
[root@fal-pygrid-26 root]# kill -9 32059
[root@fal-pygrid-26 root]# ps -p 32059
PID TTY TIME CMD
32059 ? 00:04:22 java <defunct>
[root@fal-pygrid-26 root]#
These doors still show up as being okay in the web interface.
Has anyone seen this behaviour before? And could anyone suggest a work around?
cheers all,
matt
|