Anonymous_User Absent Member.
Absent Member.
648 views

Background Process Schedule


One my server is OES11 SP1. All updates installed. Server contains the
R/W replica. At this server DNS/DHCP work at it while without any
problems. I found out that this server
periodically for a long time disappears from the Bindery-servers list on
SLP DA.
In the course of studying of a problem it became clear that a problem in
background processes scheduler in eDir. At iMonitor I see (Agent
Activity/ Background Process Schedule ) strange huge numbers,including
RNRAdvertise :

Background Processes
Process State Schedule

CheckBacklinks Waiting 12:38:09
Janitor Waiting
1193046:08:17
Limber (Connectivity Check) Waiting 2:38:01
ObitProc Waiting
1193046:27:15
PartitionPurgeProcess Waiting 0:08:04

Predicate Statistics Update Waiting 1193046:06:26

RNRAdvertise Waiting 0:38:01
RefreshBinderyContext Waiting 1193046:16:17
Repair Inactive Replicas Waiting 54:50:21
SchemaProc Waiting 3:38:17
SkulkerProc (Outbound Replication) Waiting 1193046:27:24
Update Login Attributes Waiting 1193046:22:21

In eDir tree there are OES2SP3 and Netware servers. On them this problem
isn't present. Parameters from ndsconfig get on OES2 SP3 and the same
OES11 SP1.
It would be desirable to eliminate this small problem.

Dmitry E. Rovkin


--
Dim2001ru
------------------------------------------------------------------------
Dim2001ru's Profile: https://forums.netiq.com/member.php?userid=2469
View this thread: https://forums.netiq.com/showthread.php?t=46646

Labels (1)
0 Likes
19 Replies
Anonymous_User Absent Member.
Absent Member.

Re: Background Process Schedule

I'm not sure that the backup processes you see in iMonitor are related to
your SLP issue at all. By default (at least as of a year ago when I
checked last) eDirectory would update its own SLP registration once per
hours. There was a bug causing the server to be missing from SLP's list
of services for fifteen seconds because of a timing problem, but that's
not really a very "long time" when compared to an hour-long registration
(still, it's a bug and was going to be fixed). The refresh time for SLP
registrations in eDir is configurable, but enough about this side for now.

On the SLP side of things unless you have configured DA Backup or DA
synchronization (and have multiple DAs for the latter option) if your SLP
DA is restarted then it will not know about current registrations because
it does not normally maintain a copy of its database when stopped.
Thankfully these options exist and can be easily enabled, but if you have
not done that and have restarted your DA service (or server) then that
would explain a long-time omission of the server from the list of
available services. Is this related to your case?

If nothing else I'd probably setup a LAN trace on the SLP server watching
all SLP traffic from the OES 11 server in question to see if eDir is at
least trying to register once per hour as it should. This should generate
a tiny trace to read and give a good indication that eDir is not
re-registering regularly as it should.

Good luck.
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Background Process Schedule


I once again attentively saw the log file made on SLPDA side.

Unfortunately after event:
....
Lifetime record purged. ~ service:bindery.novell:///gw2012 11:43:21 am
.....
here no any SLP registration from eDir (server name gw2012)

but on same time here successful SLP registration like:
....
DDCModifyEntry. ccode=0, service:wbem:https://gw2012:5989, DEFAULT
12:27:16 pm
DA_SREG~ service:wbem:https://gw2012:5989~ 192.168.100.207~ 12:37:01
pm
....
from gw2012 server.

Seems here problem on internal eDir scheduler.
No any warning/errors on slpd.log etc on gw2012 server.

Event:
DA_SREG~ service:bindery.novell:///gw2012~ 192.168.100.207~ 2:12:19
pm
DA_SREG_ATTR~
(svcname-ws=gw2012),(svcaddr-ws=2-1-6-c0a864cf020c000000000000000000,2-2-17-c0a864cf020c000000000000000000),(svcid-ws=000b0004-0000-0000-c000-000000000046),(version-ws=2070300-0),(host-ws=0),(enabled-ws=TRUE),(scope=DEFAULT)~
2:12:19 pm
DDCModifyEntry. ccode=0, service:bindery.novell:///gw2012, DEFAULT
2:12:19 pm
DA_SREG~ service:wbem:https://gw2012:5989~ 192.168.100.207~ 2:14:32
pm

At 14:12 pm. In 3 hours after expiring service:bindery.novell.

Dmitry E. Rovkin

P.S. On this server

gw2012:~ # ndsconfig get | grep advertise
n4u.nds.advertise-life-time=3600


--
Dim2001ru
------------------------------------------------------------------------
Dim2001ru's Profile: https://forums.netiq.com/member.php?userid=2469
View this thread: https://forums.netiq.com/showthread.php?t=46646

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Background Process Schedule

What is the RNR value just before the deregistration? What about right
after the deregistration?

I would expect it to be 0:60:00 (sixty minutes, one hour) or something
very close to that immediately after registration, so the value you showed
before of 0:38:01 is not strange to me at all; however, if that timeout is
reached and for some reason the registration is not happening then that
would be a problem, but I'd like to know if the timer is only set for an
hour to start and if it is properly resetting after getting to zero.

Also, while the debug output does not show a registration happening, that
does not necessarily mean that eDirectory is not even trying; there are
other network things that could be blocking the UDP packet to re-register
the service. I admit this is probably not the case, but before we submit
a bug against eDirectory it'd probably be worthwhile to verify that
eDirectory is indeed not even trying to register, especially if the
timeout is getting to zero and then resetting to an hour multiple times
without sending a new service advertisement. A LAN trace of all
interfaces on the eDirectory (gw2012 server) box for port 427 would
probably be a good start:

Code:
----------
sudo /usr/sbin/tcpdump -n -s 0 -i any -w /tmp/slp.cap port 427
----------

Also, if you have multiple servers it would be interesting to know if any
others are experiencing this same issue. I know you said some are not,
but what is different about them? OES vs. SLES? Versions of OES?
Proximity to the SLP service on the network?

Good luck.
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Background Process Schedule


1. n4u.nds.advertise-life-time=3600 . not changed
2. all other servers on tree: nw6,nw65,oes2sp3 have not this problem.
3. i have ndstrace log : -ALL +TIME +THREADS - i see here no regular
eDir registration on SLPDA:

(previous log)
cat ndstrace1.log | grep dver
[2013/01/31 18:29:07.0] ---------- Begin RNRAdvertise ----------
[2013/01/31 18:29:07.2] ---------- End RNRAdvertise ----------
[2013/02/01 1:23:20.943] ---------- Begin RNRAdvertise ----------
[2013/02/01 1:23:20.944] ---------- End RNRAdvertise ----------

(current log)
cat ndstrace.log | grep dver
[2013/02/01 9:23:20.0] ---------- Begin RNRAdvertise ----------
[2013/02/01 9:23:20.1] ---------- End RNRAdvertise ----------
[2013/02/01 12:33:18.598] ---------- Begin RNRAdvertise ----------
[2013/02/01 12:33:18.599] ---------- End RNRAdvertise ----------
[2013/02/01 15:07:37.77] ---------- Begin RNRAdvertise ----------
[2013/02/01 15:07:37.78] ---------- End RNRAdvertise ----------


3. I see on my smt server new January eDir and other oes stuff update.
I'll look this problem after patching.

Dmitry E. Rovkin


--
Dim2001ru
------------------------------------------------------------------------
Dim2001ru's Profile: https://forums.netiq.com/member.php?userid=2469
View this thread: https://forums.netiq.com/showthread.php?t=46646

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Background Process Schedule

Yes, the January updates for OES are now available and that should include
getting to the latest eDirectory version. If that does not fix things
then I'll see if I can get an OES 11 SP1 system built to test this.

Good luck.
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Background Process Schedule


No luck after latest OES update:

gw2012:/var/opt/novell/eDirectory/log # cat ndstrace.log | grep dver
[2013/02/03 5:42:23.0] ---------- Begin RNRAdvertise ----------
[2013/02/03 5:42:23.1] ---------- End RNRAdvertise ----------
[2013/02/03 13:42:22.0] ---------- Begin RNRAdvertise ----------
[2013/02/03 13:42:22.1] ---------- End RNRAdvertise ----------
[2013/02/03 18:58:55.112] ---------- Begin RNRAdvertise ----------
[2013/02/03 18:58:55.114] ---------- End RNRAdvertise ----------

😞


--
Dim2001ru
------------------------------------------------------------------------
Dim2001ru's Profile: https://forums.netiq.com/member.php?userid=2469
View this thread: https://forums.netiq.com/showthread.php?t=46646

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Background Process Schedule

FWIW I am not seeing the problem on my OES 11 SP1 box. Every hour I see
the RNRAdvertise lines in ndstrace and I also see the registration updated
before it even expires when querying via slptool so I am guessing either
something is odd in your eDir/OES instance or else something else
environmental is causing the issue. Are there other tests you can think
of that would help us find differences between our systems?

I do not know that my box has updated properly lately (I probably never
subscribed to the repos) so I will see if that makes a difference since
that probably means I'm on OES 11 SP1 without any later fixes.

Good luck.
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Background Process Schedule

Couple of days, no errors so far. I still need to find out how to
register OES and patch it but at least the shipping stuff with eDir 8.8
SP7 is working properly. Can you duplicate this on another box?

I was using the following command to watch slpd closely to ensure things
kept refreshing nicely, and they did:

Code:
----------
while [ 1 ] ; do echo `date` >> /tmp/slpwatch.txt; echo `slptool
unicastfindsrvs 192.168.255.106 service:ndap.novell` >> /tmp/slpwatch.txt;
echo `slptool unicastfindsrvs 192.168.255.106 service:bindery.novell` >>
/tmp/slpwatch.txt; echo >> /tmp/slpwatch.txt; echo >> /tmp/slpwatch.txt;
sleep 5; done
----------

Good luck.
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Background Process Schedule


I agree that the problem with a sheduler for RNRAdvertise can be unique
.. Whereas to correct internal eDirectory a sheduler (on this server)?
May be ndsrepair (not sure) ?


--
Dim2001ru
------------------------------------------------------------------------
Dim2001ru's Profile: https://forums.netiq.com/member.php?userid=2469
View this thread: https://forums.netiq.com/showthread.php?t=46646

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Background Process Schedule

What if you try to set the value to something else, and then back to 3600
(or just leave it set at some other value)? Perhaps that will cause a
change; as 'root':

Code:
----------
ndsconfig set n4u.nds.advertise-life-time=1800
----------


Good luck.
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Background Process Schedule


ab;225154 Wrote:
> What if you try to set the value to something else, and then back to
> 3600
> (or just leave it set at some other value)? Perhaps that will cause a
> change; as 'root':
>
> Code:
> ----------
> ndsconfig set n4u.nds.advertise-life-time=1800
> ----------
>
>
> Good luck.



Thanks for help.

1. HyperThreading Disabled (in BIOS, here 2 x Xeon E5-2660 ).
2. ndsrepair -R (repair Local Database)
3. Trying to change n4u.nds.advertise-life-time to other value and
return 3600.
No luck.
After Expiring no SLP service on my SLP DA:(
4. Trying to change to 600.
Same here - after expiring on 600 sec no service on SLPDA again.

Opened service request,but no way to resolve this issue yet 😞

May be static slp registration is real workaround ???


--
Dim2001ru
------------------------------------------------------------------------
Dim2001ru's Profile: https://forums.netiq.com/member.php?userid=2469
View this thread: https://forums.netiq.com/showthread.php?t=46646

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Background Process Schedule

In article <Dim2001ru.5qmwin@no-mx.forums.netiq.com>, Dim2001ru wrote:
> May be static slp registration is real workaround ???
>

Sometimes we just need such work-around just to get things moving,
after IBM: 'Its Better Manually'


Andy Konecny
KonecnyConsulting.ca in Toronto
----------------------------------------------------------------------
Andy's Profiles: http://forums.novell.com/member.php?userid=75037
https://forums.netiq.com/member.php?3330-konecnya

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Background Process Schedule


Static Bindery and Ndap registration in SLPDA is ok, but periodically
(rare and sporadic) executed RNRAdvertise in ndsd delete static records
😞


--
Dim2001ru
------------------------------------------------------------------------
Dim2001ru's Profile: https://forums.netiq.com/member.php?userid=2469
View this thread: https://forums.netiq.com/showthread.php?t=46646

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Background Process Schedule


Thanks for slpwatch shell script.

It shows sporadic visibility of services and after
.......
service:ndap.novell:///TPSB., 30
service:bindery.novell:///gw2012,30
continuous time they are unavailable on SLPDA
.......
Mon Feb 11 10:55:57 NOVT 2013
Mon Feb 11 10:56:27 NOVT 2013
.......


--
Dim2001ru
------------------------------------------------------------------------
Dim2001ru's Profile: https://forums.netiq.com/member.php?userid=2469
View this thread: https://forums.netiq.com/showthread.php?t=46646

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.