Daemon.raw flooded! "An operation was attempted on something that is not a
socket"
Hi
All of a sudden, over the last few weeks, I've had three instances where the daemon.raw of a client has been flooded with the message "An operation was attempted on something that is not a socket." which has filled up the C: drive.
I've found that this issue should have been resolved in Networker 7.6.1.4;
NW125997 nsrexecd: client’s daemon.raw flooded with "An operation was attempted on something that is not a socket" message.
I am currently using 7.6.2.1, so assume it should have been fixed in this release? I've just completed a rollout of 7.6.2.1 to fourteen Networker environments (Due to the issue restoring file security in 7.6.1) and would like to hear anyone elses experience with this before I start rolling out later versions.
The hot fix you reference is indeed in the version you are running (it was in the initial 7.6.2 software and you are running first Cumulative build).
I would suggest opening a Support case with EMC so your issue can be investigated further. Please reference the hot fix you have identified in the notes so this is taken into account in initial investigation.
same issue...on 7.6.2.4...still same,...Networker design must able to rotate the logs live...sth that EMC needs to work on...you have to stop service, rename the daemon log to say .old and start service as a workaround....and find the root cause...last time ours were due to anti virus
This does add some housekeeping to NetWorker but currently it takes effect when the software is restarted. There is work within EMC to add a rolling housekeeping situation where the logs would be rotated without having to stop the software.
I agree in the further investigation for the reason of the daemon getting flooded with those messages, however there is indeed a way to control the size of NetWorker logs and the max number of versions, as described in here:
The real problem I have is that its happened three times in the past couple of weeks to three different clients on two different servers (All running 7.6.2.1). It floods Daemon.raw and fills up the C: drive in a couple of hours, killing the client server. This has now happened to one of our critical live servers over night and my manager needs us to react! He wants me to relocate Daemon.raw onto the D: drive, so if it does happens again, it won't kill the server, the only problem with that plan is that it could happen to any client at any time and we currently have 400 Clients split over 14 Networker servers, all would need updating manually, very time consuming.
We could schedule a restart of the Networker service as suggested, although would potentially have to schedule this every 2-3 hours, as that is how fast the daemon.raw seems to grow. Plus this would also probably mean visiting every client to set this up too, again very time consuming.
Any further suggestions would be greatfully received. I'd like to hear from Thierry101 about their Anti Virus issue, as we too have just rolled out a new release of Sophos within the last Month.
I would open a Support case with EMC - they should be able to assist you in diagnosing the source of the messages which are being produced if you have not already done so. We can keep forum as a Parallel investigation. I would also mention the AV upgrade as it may be relevant.
try disable your AV and stop NW server service, rename daemon and start ...see if it floods again...if it doesnt then its ur AV...and you have to exclude your NW install paths from backup server,SN and clients because AV thinks its "virus" where the nsr changes frequently and the size grows...and that changes are due to backup/restore/clone etc activities which is of course not "virus" activities...good luck...
masonb
445 Posts
1364
0
Posted January 31st, 2012 04:00
Gavin,
The hot fix you reference is indeed in the version you are running (it was in the initial 7.6.2 software and you are running first Cumulative build).
I would suggest opening a Support case with EMC so your issue can be investigated further. Please reference the hot fix you have identified in the notes so this is taken into account in initial investigation.
Regards,
Bill Mason