Thread: [Openslp-users] slpd seems to hijack the port I'm using in my application
Brought to you by:
jcalcote
Menu
▾
▴
openslp-users
|
From: Robert H. <rh...@hs...> - 2012-10-12 08:38:06
|
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-15">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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).<br>
<br>
The problem is that slpd seems to occupy the port I'm using for my
application. Let me explain...<br>
<br>
Before I start my application, "<tt>lsof -i</tt>" lists the
following spld related entries:<br>
<br>
<tt>COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME</tt><tt><br>
</tt><tt>slpd 2786 daemon 4u IPv4 6415 0t0 TCP
localhost:svrloc (LISTEN)</tt><tt><br>
</tt><tt>slpd 2786 daemon 5u IPv4 6416 0t0 TCP
DebianWheezy.local:svrloc (LISTEN)</tt><tt><br>
</tt><tt>slpd 2786 daemon 6u IPv4 6417 0t0 UDP
239.255.255.253:svrloc </tt><tt><br>
</tt><tt>slpd 2786 daemon 7u IPv4 6418 0t0 UDP
DebianWheezy.local:svrloc </tt><tt><br>
</tt><tt>slpd 2786 daemon 8u IPv4 6419 0t0 TCP
3724G-21104-2.hsr.ch:svrloc (LISTEN)</tt><tt><br>
</tt><tt>slpd 2786 daemon 9u IPv4 6420 0t0 UDP
239.255.255.253:svrloc </tt><tt><br>
</tt><tt>slpd 2786 daemon 10u IPv4 6421 0t0 UDP
3724G-21104-2.hsr.ch:svrloc </tt><br>
<br>
Then I start my application which registers the following two
services with SLP:<br>
<tt>service:TrackingNode.ADEC:CP://10.0.2.15:1234/1c736ed2-e8b7-545c-998a-2ce095e600ea</tt><tt><br>
</tt><tt>service:TrackingNode.ADEC:CP://192.168.0.24:1234/1c736ed2-e8b7-545c-998a-2ce095e600ea</tt><br>
<br>
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??). "<tt>lsof -i</tt>" shows this:<br>
<br>
<tt>COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME</tt><tt><br>
</tt><tt><b>TrackingN 4795 root 6u IPv4 12170 0t0
TCP *:1234 (LISTEN)</b></tt><tt><br>
</tt><tt>TrackingN 4795 root 7u IPv4 12186 0t0 TCP
localhost:45272->localhost:svrloc (ESTABLISHED)</tt><tt><br>
</tt><tt>slpd 4805 daemon 0u IPv4 12189 0t0 TCP
localhost:svrloc->localhost:45272 (ESTABLISHED)</tt><tt><br>
</tt><tt>slpd 4805 daemon 1u IPv4 12204 0t0 UDP
*:37734 </tt><tt><br>
</tt><tt>slpd 4805 daemon 2u IPv4 12199 0t0 UDP
*:49554 </tt><tt><br>
</tt><tt>slpd 4805 daemon 4u IPv4 12176 0t0 TCP
localhost:svrloc (LISTEN)</tt><tt><br>
</tt><tt>slpd 4805 daemon 5u IPv4 12177 0t0 TCP
DebianWheezy.local:svrloc (LISTEN)</tt><tt><br>
</tt><tt><b>slpd 4805 daemon 6u IPv4 12170 0t0
TCP *:1234 (LISTEN)</b></tt><tt><br>
</tt><tt>slpd 4805 daemon 7u IPv4 12178 0t0 UDP
239.255.255.253:svrloc </tt><tt><br>
</tt><tt>slpd 4805 daemon 8u IPv4 12179 0t0 UDP
DebianWheezy.local:svrloc </tt><tt><br>
</tt><tt>slpd 4805 daemon 9u IPv4 12180 0t0 TCP
3724G-21104-2.hsr.ch:svrloc (LISTEN)</tt><tt><br>
</tt><tt>slpd 4805 daemon 10u IPv4 12181 0t0 UDP
239.255.255.253:svrloc </tt><tt><br>
</tt><tt>slpd 4805 daemon 11u IPv4 12182 0t0 UDP
3724G-21104-2.hsr.ch:svrloc </tt><br>
<br>
And then, when I quit my application, slpd keeps listening on port
1234:<br>
<br>
<tt>COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME</tt><tt><br>
</tt><tt>slpd 4816 daemon 4u IPv4 12317 0t0 TCP
localhost:svrloc (LISTEN)</tt><tt><br>
</tt><tt>slpd 4816 daemon 5u IPv4 12318 0t0 TCP
DebianWheezy.local:svrloc (LISTEN)</tt><tt><br>
</tt><b><tt>slpd 4816 daemon 6u IPv4 12170 0t0
TCP *:1234 (LISTEN)</tt></b><tt><br>
</tt><tt>slpd 4816 daemon 7u IPv4 12319 0t0 UDP
239.255.255.253:svrloc </tt><tt><br>
</tt><tt>slpd 4816 daemon 8u IPv4 12320 0t0 UDP
DebianWheezy.local:svrloc </tt><tt><br>
</tt><tt>slpd 4816 daemon 9u IPv4 12321 0t0 TCP
3724G-21104-2.hsr.ch:svrloc (LISTEN)</tt><tt><br>
</tt><tt>slpd 4816 daemon 10u IPv4 12322 0t0 UDP
239.255.255.253:svrloc </tt><tt><br>
</tt><tt>slpd 4816 daemon 11u IPv4 12323 0t0 UDP
3724G-21104-2.hsr.ch:svrloc </tt><tt><br>
</tt><tt>slpd 4816 daemon 13u IPv4 12326 0t0 UDP
*:47496 </tt><br>
<br>
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.<br>
<br>
Can anyone explain what's happening here? Why does slpd hijack my
port?<br>
</body>
</html>
|
|
From: Nick W. <ne...@wi...> - 2012-10-15 14:51:57
|
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 <rh...@hs...> 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 > service:TrackingNode.ADEC:CP:// > 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 > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openslp-users > > |
|
From: Robert H. <rh...@hs...> - 2012-10-16 07:02:20
|
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
> <rh...@hs... <mailto:rh...@hs...>> 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
> Ope...@li...
> <mailto:Ope...@li...>
> 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
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openslp-users
>
|
|
From: Robert H. <rh...@hs...> - 2012-10-16 09:32:43
|
I tried to check if I can reproduce the problem described in my original post with the latest SVN revision of OpenSLP. But I just can't install it properly (on Debian). Here is what I tried: 1) run "./autogen.sh" 2) run "./configure --enable-static=yes --enable-shared=no --prefix=/usr" 3) run "make" 4) run "make install" 5) step 4 does not create the start-stop-script in /etc/init.d, but I found the script in ../openslp.misc/debian/init.d. I copied that as slpd to /etc/init.d and set the execution flag. Now it looks like I can start slpd by running "/etc/init.d/slpd start". It shows up in the list of running processes afterwards. But running "/etc/init.d/slpd stop" does not stop the process, it keeps running. I guess the problem is related to the PID file (/var/run/slpd.pid is not being created). What am I doing wrong? I also tried to create the Debian package as described in ../openslp.misc/Readme.debain but that doesn't work either (some documentation files are missing). I guess these scripts are for building the 1.2 release package and they don't work with version 2.0 anymore. Any help on getting this to work is appreciated! 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 > <rh...@hs... <mailto:rh...@hs...>> 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 > Ope...@li... > <mailto:Ope...@li...> > 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 > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openslp-users > |
|
From: Nick W. <ne...@wi...> - 2012-10-16 14:42:39
|
Is the pid file being created in /usr/local/var/run? Otherwise, you should be able to use the -p option to specify its location. Since you can make it run, does the problem occur? --Nick On Tue, Oct 16, 2012 at 4:30 AM, Robert Hegner <rh...@hs...> wrote: > I tried to check if I can reproduce the problem described in my original > post with the latest SVN revision of OpenSLP. But I just can't install > it properly (on Debian). Here is what I tried: > > 1) run "./autogen.sh" > 2) run "./configure --enable-static=yes --enable-shared=no --prefix=/usr" > 3) run "make" > 4) run "make install" > 5) step 4 does not create the start-stop-script in /etc/init.d, but I > found the script in ../openslp.misc/debian/init.d. I copied that as > slpd to /etc/init.d and set the execution flag. > > Now it looks like I can start slpd by running "/etc/init.d/slpd start". > It shows up in the list of running processes afterwards. But running > "/etc/init.d/slpd stop" does not stop the process, it keeps running. I > guess the problem is related to the PID file (/var/run/slpd.pid is not > being created). What am I doing wrong? > > I also tried to create the Debian package as described in > ../openslp.misc/Readme.debain but that doesn't work either (some > documentation files are missing). I guess these scripts are for building > the 1.2 release package and they don't work with version 2.0 anymore. > > Any help on getting this to work is appreciated! > > 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 > > <rh...@hs... <mailto:rh...@hs...>> 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 > > Ope...@li... > > <mailto:Ope...@li...> > > 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 > > Ope...@li... > > 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 > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openslp-users > |
|
From: Robert H. <rh...@hs...> - 2012-10-17 10:52:55
|
Ok I managed to setup the latest SVN revision of OpenSLP now. I had to
modify the start script a little bit, like this:
start-stop-daemon --pidfile /var/run/$NAME.pid \
--exec $DAEMON --start -- -p /var/run/$NAME.pid
Now the bad news is that I'm experiencing exactly the same port
hijacking behaviour as before :(
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
>> <rh...@hs... <mailto:rh...@hs...>> 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
>> Ope...@li...
>> <mailto:Ope...@li...>
>> 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
>> Ope...@li...
>> 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
>
|
|
From: Nick W. <ne...@wi...> - 2012-10-17 15:24:56
|
What does your slpd.log show?
On Wed, Oct 17, 2012 at 5:50 AM, Robert Hegner <rh...@hs...> wrote:
> Ok I managed to setup the latest SVN revision of OpenSLP now. I had to
> modify the start script a little bit, like this:
>
> start-stop-daemon --pidfile /var/run/$NAME.pid \
> --exec $DAEMON --start -- -p /var/run/$NAME.pid
>
> Now the bad news is that I'm experiencing exactly the same port
> hijacking behaviour as before :(
>
>
>
> 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
> >> <rh...@hs... <mailto:rh...@hs...>> 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
> >> Ope...@li...
> >> <mailto:Ope...@li...>
> >> 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
> >> Ope...@li...
> >> 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
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openslp-users
>
|
|
From: Robert H. <rh...@hs...> - 2012-10-17 15:33:47
|
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
>> <rh...@hs... <mailto:rh...@hs...>> 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
>> Ope...@li...
>> <mailto:Ope...@li...>
>> 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
>> Ope...@li...
>> 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
>
|
|
From: Nick W. <ne...@wi...> - 2012-10-17 15:45:07
|
Someone on the devel list with more experience working with linux daemons will need to make this fix. And they should patch the debian start-stop script as well as earlier explained in this email chain. We should do this before the code freeze. Robert, thanks for finding these issues! --Nick On Wed, Oct 17, 2012 at 10:30 AM, Robert Hegner <rh...@hs...> wrote: > 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 > > |
|
From: John C. <joh...@gm...> - 2012-10-18 01:08:33
|
Hi all -
I've enhanced the daemonizing code in slpd_main.c - my changes are committed
in rev 1692. Basically, I moved the call to Daemonize up above all the
initialization so we don't open all our socket handles before daemonizing -
this is generally considered standard procedure.
I then added the loop that Robert wanted that closes the first 8k file
handles. A better way of doing this is to freopen the standard handles to
/dev/null so that someone attempting to write to the handle doesn't cause
flush to hang on shutdown. Luckily, we don't use printf in our production
code, so this isn't really an issue for slpd.
Finally, I moved the setuid code out of Daemonize into its own routine,
DropPrivileges, and places a call to that function where the call to
Daemonize used to be. The reason Daemonize was called so late was so we
could open our privileged sockets before we drop privs. Another standard
procedure is to daemonize early and drop privs as soon as we can, but no
sooner.
I've built and tested this code on Ubuntu 12.04. It's a *nix-only source
file, so I don't think these changes will have any effect on Windows, but
others should give it a try on other Unix platforms. I don't expect any
problems, but you never know.
Hope this helps,
John
From: Nick Wagner [mailto:ne...@wi...]
Sent: Wednesday, October 17, 2012 9:45 AM
To: Robert Hegner
Cc: ope...@li...; ope...@li...
Subject: Re: [Openslp-users] slpd seems to hijack the port I'm using in my
application
Someone on the devel list with more experience working with linux daemons
will need to make this fix. And they should patch the debian start-stop
script as well as earlier explained in this email chain. We should do this
before the code freeze.
Robert, thanks for finding these issues!
--Nick
On Wed, Oct 17, 2012 at 10:30 AM, Robert Hegner <rh...@hs...> wrote:
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
|
|
From: Robert H. <rh...@hs...> - 2012-10-18 13:50:02
|
Thank you for the fix. I tried it and it solves my problem :) As mentioned earlier it would be great if someone could also have a look at the Debian related stuff. It looks like the start/stop script needs some work and I also did not manage to build the Debian package as described in openslp.misc/Readme.debian. Robert Am 18.10.2012 03:08, schrieb John Calcote: > Hi all – > > I’ve enhanced the daemonizing code in slpd_main.c – my changes are > committed in rev 1692. Basically, I moved the call to Daemonize up above > all the initialization so we don’t open all our socket handles before > daemonizing – this is generally considered standard procedure. > > I then added the loop that Robert wanted that closes the first 8k file > handles. A better way of doing this is to freopen the standard handles > to /dev/null so that someone attempting to write to the handle doesn’t > cause flush to hang on shutdown. Luckily, we don’t use printf in our > production code, so this isn’t really an issue for slpd. > > Finally, I moved the setuid code out of Daemonize into its own routine, > DropPrivileges, and places a call to that function where the call to > Daemonize used to be. The reason Daemonize was called so late was so we > could open our privileged sockets before we drop privs. Another standard > procedure is to daemonize early and drop privs as soon as we can, but no > sooner. > > I’ve built and tested this code on Ubuntu 12.04. It’s a *nix-only source > file, so I don’t think these changes will have any effect on Windows, > but others should give it a try on other Unix platforms. I don’t expect > any problems, but you never know… > > Hope this helps, > > John > > *From:*Nick Wagner [mailto:ne...@wi...] > *Sent:* Wednesday, October 17, 2012 9:45 AM > *To:* Robert Hegner > *Cc:* ope...@li...; > ope...@li... > *Subject:* Re: [Openslp-users] slpd seems to hijack the port I'm using > in my application > > Someone on the devel list with more experience working with linux > daemons will need to make this fix. And they should patch the debian > start-stop script as well as earlier explained in this email chain. We > should do this before the code freeze. > > Robert, thanks for finding these issues! > > --Nick > > On Wed, Oct 17, 2012 at 10:30 AM, Robert Hegner > <rh...@hs... > <mailto:rh...@hs...>> wrote: > > 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 > > > > ------------------------------------------------------------------------------ > 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 > > > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X