#153 OpenSLP unable to discover once the system is booted

[Vivek Nagaraj]

Details and versions used are as follows:

OS: SUSE Linux Enterprise Server 12 (x86_64)
VERSION = 12
PATCHLEVEL = 0

System details: Linux linux-c8s6 3.12.28-4-default #1 SMP Thu Sep 25 17:02:34 UTC 2014 (9879bd4) x86_64 x86_64 x86_64 GNU/Linux

OpenSLP version:
openslp-2.0.0-2.9.x86_64
openslp-server-2.0.0-2.9.x86_64
openslp-32bit-2.0.0-2.9.x86_64
yast2-slp-3.1.7-1.24.x86_64

During bootup time, one of the Broadcom internal application is registering with SLP using SLPOpen and SLPReg API calls. As per application logs, both the calls are successful and the same is evident even in /var/log/slpd.log after enabling logs in /etc/slp.conf file. Please find attached the same.

However, when I try to query using slptool for the service, the same is not listed. I am issuing the following command:
slptool findsrvs service:x-mgmt.avago:lsa

Workaround: Restart slpd services by issuing the following command and restart application to start afresh with the registration.
killall slpd

The above behavior is also confirmed using slptool.

[John Calcote]

Hi Vivek -

Apps that register services with OpenSLP have a time-to-live value and are supposed to refresh the registration before that value expires. For example, an application that registers with OpenSLP using the OpenSLP client SDK might do so as follows:

SLPHandle * hSlp;
SLPError slperr = SLPOpen(NULL, SLP_FALSE, &hSlp);
if (slperr == SLP_OK) {
    slperr = SLPReg(hSlp,
            serviceUrl,
            300,         // 5 minutes
            0,
            attributes,
            SLP_TRUE,
            report,
            &callbackerr);
    while (slperr && !shutDown) {
        sleep(295);    // *almost* 5 minutes
        slperr = SLPReg(hSlp,
                serviceUrl,
                300,
                0,
                attributes,
                SLP_FALSE,
                report,
                &callbackerr);
    }
    SLPDereg(hSlp, serviceUrl, report, &callbackerr);
    SLPClose(hSlp);
}

The sole job of this thread is to keep service registrations refreshed with SLP. The point of this mechanism is to allow stale registrations to expire within a reasonable amount of time if the service dies and is unable to deregister properly.

That's the theory anyway. In practice, apps often register for SLP_LIFETIME_MAXIMUM, which is the largest 16-bit value - 65,535 (seconds) - about 18 hours. OpenSLP treats this value specially in that it simply assumes when this value is used that the registration should never expire. It also captures the pid of the registering service and adds it to a pid-watcher thread - if the pid-watcher sees the pid go away, it kills all associated registrations.

I'm guessing your service is using the LIFETIME MAX value - other services would not notice a boot issue because they would "refresh" a problem registration within a few minutes and no one would be the wiser.

Do you know how your service works? I'll try to see if I can determine what might be going wrong based on your log files, but it's not likely to shed enough light on the issue.

John

[John Calcote]

This could be related to BUG#139, which affects all SLP registrations. 139 has been fixed and closed. If you still care, please check your system to see if it's been fixed with the latest mercurial code base.

John