I've seen a log rotation where the input file did not get re-opened, and am
working on troubleshooting that.
For the SEC process that failed, sending a SIGUSR2 failed, but sending a
SIGABRT worked.
(both sent as the same user as the process owner)
The input file for that process is an NFS mounted read-only backed file system,
to which I have no real access for experimentation.
I created a baby SEC config file for testing, and specified a local filesystem,
and was unable to recreate the failure.
I tried using "mv input_orig input_new; touch input_new", and "cp /dev/null >>
input_orig".
I used non-detached mode, as opposed to detached mode for the failing config,
though I wouldn't expect that to make a difference.
I'm currently thinking that it might have to do with the NFS mount options,
perhaps specifically the locking methods, or maybe the soft vs. hard mount.
The mtab entry (redhat 7.9) for this includes the following options:
foo.ucsd.edu:/remotefilesystem /localfilemountdir nfs
ro,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,soft,nolock,proto=udp,timeo=11,retrans=3,sec=sys,mountaddr=AAA.BBB.CCC.DDD,mountvers=3,mountport=4002,mountproto=udp,local_lock=all,addr=AAA.BBB.CCC.DDD
0 0
The same SEC config running on a Solaris 11 box with the same NFS mounted
filesystem, doesn't have this problem. The mnttab file there has these options:
foo.ucsd.edu:/remotefilesystem /localfilenountdir nfs
ro,nodevices,noquota,vers=3,proto=tcp,xattr,zone=ratbert2,sharezone=1,dev=9540001
1613782895
Ideas anyone?
--
Brian Parent
Information Technology Services Department
ITS Computing Infrastructure Operations Group
its-ci-ops-h...@ucsd.edu (team email address for Service Now)
UC San Diego
(858) 534-6090
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
