strange message in networkers daemon.log

[spaceball]

Hi,
While we've some strange behaviours on some of our Networker clients ( complaining server busy during save-request)
I took a look on LNS daemon.log and found messages like:
"02/24/03 11:41:52 nsrd: re-setting overall number of authorized save sessions, changing value from (1) to (0)"
does someone have a hint for me?
The Value is decreasing and increasing several times in the past on It's (networker) own.
We're running on Networker 6.1.3 Build 428

Regards spaceball

 

[sdeb]

It might not be an error message.

It is in relation with "parrallelism" and "target sessions" settings.

Sometimes Networker "optimizes" itself the number of save sessions by increasing or decreasing this values.

For example, if your server receives more save sessions than the allowed number of target sessions, it will increase automatically the target sessions.

In my opinion, It must do it to don't have to much "inactivity timeouts" generated by save streams waiting for an idle drive (or an available target sessions).

Hope this helps.

 

[spaceball]

Hi sdeb,

Look's like You're right, that makes sense.

Thx & Regards spaceball

 

[wallace88]

Actually, the message itself is informational only. And yes, it is related in a distant way to target sessions and server parallelism.

Think of a the number of save sessions as the number of savesets that are being processed by nsrmmd daemon. This daemon processes the save streams and directs them to a backup device.

Think of an Authorized save sessions as the number of savesets that have been authorized to be processed by the master NetWorker daemon nsrd.

Normally, these two values should be the same, but sometimes, when the systems are busy, these two values become out of sync. When NetWorker realizes this, it resets this value, and generates this message in the daemon.log.

Although the message itself is not a problem, it could indicate that there is either a issue with the network, or that the backup server is very busy and can't keep up with the backup streams. Look in the daemon.log around this message for further clues, and open a support call with Legato if you suspect a problem.