After an otherwise successful upgrade to Networker 8.1.2, we get a warning message every sunday:
NetWorker index: (warning) Detected error with client id(s):
This is issued as a result of a weekly run of DefaultNsrclientfixTask, a new task in Networker 8.
The corresponding log entries on the server have no additional info, e.g.
71193 03/29/15 07:00:00 0 0 0 2938636032 3219 0 nsrhost.domain nsrd NSR info Task Manager Info: Starting 'NSR task' 'DefaultNsrclientfixTask'
71193 03/29/15 07:00:01 0 0 0 2938636032 3219 0 nsrhost.domain nsrd NSR info Index Warning: Detected error with client id(s):
71193 03/29/15 07:00:02 0 0 0 2938636032 3219 0 nsrhost.domain nsrd NSR info Task Manager Info: 'NSR task' 'DefaultNsrclientfixTask' succeeded. Job id '64381'
Manual execution of the nsrclientfix command gives the following output:
host:~ # nsrclientfix -a - -p
nsrhost.domain, nsrhost, nmchost.domain
With the help of our supporter, we looked into the issue, but were not able to solve it. We even did a deletion and redefinition of the listed client entries, but nothing changed.
EMC supports recommendation now is to just disable the task.
I guess that the task DefaultNsrclientfixTask has been introduced with a good reason, and should better not be disabled.
This is to avoid issues with duplicate clientid and similar. Do you get the same when not using -p? Obviosuly, nsrhost and nmchost may refer to backup server host and NMC server, but I assume you or someone else made those entries in /etc/hosts at some point? Or are they really that called? (certainly domain is not domain ). To see if you should/could ignore it, do mminfo queries for them and check clientid associated.
Actually, manual is clear on this:
The file read in and output are of the same format. The file consists of a comma separated list of clients separated by newlines. The number of clients on the line determines the actions taken.
When there is only one client on the line it means it is marked to be purged. This will not show up during the analysis step unless the -p flag is used. Clients are usually reported for purging (when requested) when an old client exists with no resource or media database entries. This is caused by either expired decommissioned clients or from merging one client into another.
More than one client
More than one client means that the clients listed are to be merged together. The first name in the list is the primary name whose name and client ID will be preserved (if it already exists). The following names (secondary names) will all be merged into the primary name. Any client resources of the secondary names will be renamed to the primary name and the alias lists of all clients will be combined. The media database entires will also have their client IDs and names merged into the primary name. At this point the index of the primary name is unlikely to be accurate. The two approaches to take are to either leave it and just have the next backup potentially back up more data one time or to try to use scanner(8) to scan in the index.
So, in your case you have both examples.
thanks. All names output are meant to address one client, actually referring to the server. I had a deeper look at the client resouces, and from the output of nsradmin I could verify that all three matching client entries have the same client id.
I was able to reduce the output by adding a further alias to /etc/hosts to cover nmchost:
host:~ # nsrclientfix -a - -p
btw. the output is the same when I omit the -p switch. Now I'm a littly bit puzzled, as nsrhost.domain and nsrhost are addressed as aliases in /etc/hosts.
From the installation guide:
The name of the host that the hostname command returns on the system must
match the name that the IP address resolves to when using nslookup.
In our installation, this is true, at least when I issue a "hostname --long", as "hostname" alone does not return the FQDN that nslookup returns.
Should we attempt to fix the issue by merging "nsrhost.domain, nsrhost", specifying it as input to nsrclientfix?
I personally didn't work with this nsrclientfix, but I remember there was KB which instructed it to be used when requested by support. I assume if something goes wrong you can get in trouble. If they have same client id, I wonder if in mdb they are seen as client owner for different sets... for example if you do query based on clientid, do you see under client column sometimes one name, sometimes other name. Normally, if that is not the case, I'm not sure why is this reported in the first place, but you may wish also to check area under /nsr/index to see if you have separate (or nested) folders for these two reported.