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
>> <[email protected] <mailto:[email protected]>> 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
>> [email protected]
>> <mailto:[email protected]>
>> 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
>> [email protected]
>> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/openslp-users
