Ok I found out what's wrong. And I would consider this as a bug in OpenSLP.
I'm a Linux newbie but The Linux Programming Interface by Michael
Kerrisk (a great book, by the way) helped me understand what's going on.
You can see in my first post that when slpd listens to the same port as
my application, it also uses the same file descriptor.
As I wrote earlier, I use system() to run the start/stop script of slpd.
According to Kerrisk's book, system() is typically implemented using a
combination of fork() (which copies all open file descriptors) and
exec() (which does not close any file descriptors). So slpd inherits my
open file descriptors when I start it from within my application.
In chapter 37 of his book, Kerrisk also describes the seven steps for
daemonizing a program. Step 6 is:
"Close all open file descriptors that the daemon has inherited from its
parent. (A daemon may need to keep certain inherited file descriptors
open, [...]"
And he also provides some example code showing how to accomplish this:
maxfd = sysconf(_SC_OPEN_MAX);
if (maxfd == -1)
maxfd = BD_MAX_CLOSE; // 8192 in his example
for (fd = 0; fd < maxfd; fd++)
close(fd);
I had a look at the OpenSLP source code and I found that Daemonize() (in
slpd_main.c) does not close all open file descriptors (it only closes
descriptors 0 to 2 under some condition).
I tried to close all file descriptors in Daemonize() but it seemed to
cause some problems. I guess that slpd has already opened some of its
own sockets at that time, which are then being closed again.
But adding
for (i = 3; i < 8192; i++)
close(i);
at the beginning of main() solves all my problems :)
Something like this should be in Daemonize() and not at the beginning of
main(), but I guess someone who is familiar with the initialization code
of slpd should have a look at this.
I hope this change will make it into Release of version 2.0
Robert
Am 16.10.2012 08:59, schrieb Robert Hegner:
> Yes it happens with any port.
>
> I want to try it with version 2.0 but I have some problems getting it to
> work (I'm new to the Linux world...). I managed to build it but I
> couldn't start/stop slpd properly. I'll have a look at this again today.
>
> You might have noticed in the lsof -i listings in my original post that
> the PID of slpd changes. The reason is that my application restarts slpd
> under certain conditions to make sure its service is published on all
> available network interfaces. The application starts and stops slpd by
> calling (as root):
> int ret = system("/bin/sh -e /etc/init.d/slpd stop");
> int ret = system("/bin/sh -e /etc/init.d/slpd start");
>
> Do you think this could cause the problem? Is this the proper way to
> programmatically restart slpd under Linux (Debian)? Under Windows I use
> the scmanager API and it works like a charm (with version 2.0, I've
> never tested it with version 1.x under Windows). I'll try and check how
> version 2.0 behaves in this scenario later today.
>
> Gavin Lambert posted a patch in the developers newsgroup to make slpd
> re-initialize its interfaces by sending it a signal. It would be great
> if some mechanism like this made it into the release version of OpenSLP
> 2.0. In my scenario I would not have to restart spld anymore.
>
> PS: It would make things much easier if version 2.0 came as a prebuilt
> Debian package, so I'm glad to hear that it will soon reach release
> status. Do you think it will make it into Debian Wheezy (which I think
> will soon change from testing to stable)?
>
> Thanks,
> Robert
>
>
> Am 15.10.2012 16:51, schrieb Nick Wagner:
>> If you try some other port, does SLP hijack that too? We're nearing
>> release on version 2.0, would you like to try that and see if if you
>> have a similar problem? I don't believe we're doing anything in the
>> current code that would cause that side effect, and 1.2.1 was a long
>> time ago.
>>
>> --Nick
>>
>> On Fri, Oct 12, 2012 at 3:35 AM, Robert Hegner
>> <rheg...@hsr.ch <mailto:rheg...@hsr.ch>> wrote:
>>
>> I recently ported my application from Windows to Linux and now I'm
>> experiencing some strange problem when running it under Debian
>> together with OpenSLP 1.2.1-9 (this is the version that comes out of
>> the box with Debian).
>>
>> The problem is that slpd seems to occupy the port I'm using for my
>> application. Let me explain...
>>
>> Before I start my application, "lsof -i" lists the following spld
>> related entries:
>>
>> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
>> slpd 2786 daemon 4u IPv4 6415 0t0 TCP
>> localhost:svrloc (LISTEN)
>> slpd 2786 daemon 5u IPv4 6416 0t0 TCP
>> DebianWheezy.local:svrloc (LISTEN)
>> slpd 2786 daemon 6u IPv4 6417 0t0 UDP
>> 239.255.255.253:svrloc
>> slpd 2786 daemon 7u IPv4 6418 0t0 UDP
>> DebianWheezy.local:svrloc
>> slpd 2786 daemon 8u IPv4 6419 0t0 TCP
>> 3724G-21104-2.hsr.ch:svrloc (LISTEN)
>> slpd 2786 daemon 9u IPv4 6420 0t0 UDP
>> 239.255.255.253:svrloc
>> slpd 2786 daemon 10u IPv4 6421 0t0 UDP
>> 3724G-21104-2.hsr.ch:svrloc
>>
>> Then I start my application which registers the following two
>> services with SLP:
>>
>> service:TrackingNode.ADEC:CP://10.0.2.15:1234/1c736ed2-e8b7-545c-998a-2ce095e600ea
>> <http://10.0.2.15:1234/1c736ed2-e8b7-545c-998a-2ce095e600ea>
>>
>> service:TrackingNode.ADEC:CP://192.168.0.24:1234/1c736ed2-e8b7-545c-998a-2ce095e600ea
>> <http://192.168.0.24:1234/1c736ed2-e8b7-545c-998a-2ce095e600ea>
>>
>> Of course my application opens a socket to listen to port 1234. Now
>> comes the part that surprised me: slpd also begins to listen to port
>> 1234 (why??). "lsof -i" shows this:
>>
>> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
>> *TrackingN 4795 root 6u IPv4 12170 0t0 TCP *:1234
>> (LISTEN)*
>> TrackingN 4795 root 7u IPv4 12186 0t0 TCP
>> localhost:45272->localhost:svrloc (ESTABLISHED)
>> slpd 4805 daemon 0u IPv4 12189 0t0 TCP
>> localhost:svrloc->localhost:45272 (ESTABLISHED)
>> slpd 4805 daemon 1u IPv4 12204 0t0 UDP *:37734
>> slpd 4805 daemon 2u IPv4 12199 0t0 UDP *:49554
>> slpd 4805 daemon 4u IPv4 12176 0t0 TCP
>> localhost:svrloc (LISTEN)
>> slpd 4805 daemon 5u IPv4 12177 0t0 TCP
>> DebianWheezy.local:svrloc (LISTEN)
>> *slpd 4805 daemon 6u IPv4 12170 0t0 TCP *:1234
>> (LISTEN)*
>> slpd 4805 daemon 7u IPv4 12178 0t0 UDP
>> 239.255.255.253:svrloc
>> slpd 4805 daemon 8u IPv4 12179 0t0 UDP
>> DebianWheezy.local:svrloc
>> slpd 4805 daemon 9u IPv4 12180 0t0 TCP
>> 3724G-21104-2.hsr.ch:svrloc (LISTEN)
>> slpd 4805 daemon 10u IPv4 12181 0t0 UDP
>> 239.255.255.253:svrloc
>> slpd 4805 daemon 11u IPv4 12182 0t0 UDP
>> 3724G-21104-2.hsr.ch:svrloc
>>
>> And then, when I quit my application, slpd keeps listening on port 1234:
>>
>> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
>> slpd 4816 daemon 4u IPv4 12317 0t0 TCP
>> localhost:svrloc (LISTEN)
>> slpd 4816 daemon 5u IPv4 12318 0t0 TCP
>> DebianWheezy.local:svrloc (LISTEN)
>> *slpd 4816 daemon 6u IPv4 12170 0t0 TCP *:1234
>> (LISTEN)*
>> slpd 4816 daemon 7u IPv4 12319 0t0 UDP
>> 239.255.255.253:svrloc
>> slpd 4816 daemon 8u IPv4 12320 0t0 UDP
>> DebianWheezy.local:svrloc
>> slpd 4816 daemon 9u IPv4 12321 0t0 TCP
>> 3724G-21104-2.hsr.ch:svrloc (LISTEN)
>> slpd 4816 daemon 10u IPv4 12322 0t0 UDP
>> 239.255.255.253:svrloc
>> slpd 4816 daemon 11u IPv4 12323 0t0 UDP
>> 3724G-21104-2.hsr.ch:svrloc
>> slpd 4816 daemon 13u IPv4 12326 0t0 UDP *:47496
>>
>> Now when I restart my application and it tries to open a socket to
>> listen to port 1234 again, I get an "Address already in use" error,
>> since slpd still occupies that port.
>>
>> Can anyone explain what's happening here? Why does slpd hijack my port?
>>
>>
>> ------------------------------------------------------------------------------
>> Don't let slow site performance ruin your business. Deploy New Relic APM
>> Deploy New Relic app performance management and know exactly
>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>> http://p.sf.net/sfu/newrelic-dev2dev
>> _______________________________________________
>> Openslp-users mailing list
>> Openslp-users@lists.sourceforge.net
>> <mailto:Openslp-users@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/openslp-users
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Don't let slow site performance ruin your business. Deploy New Relic APM
>> Deploy New Relic app performance management and know exactly
>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>> http://p.sf.net/sfu/newrelic-dev2dev
>>
>>
>>
>> _______________________________________________
>> Openslp-users mailing list
>> Openslp-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/openslp-users
>>
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
>
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Openslp-users mailing list
Openslp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openslp-users
