openslp-devel — development futures

Re: [Openslp-devel] 2.0 release imminent

[Me <da...@gm...>]

Thanks John.  Available at
ftp://ftp.novell.com/outgoing/openslp-1.2.0-172.22.1.src.rpm with md5
checksum: 494ed3b4f2453fbf2b47ab48707b1173

This file includes the base openslp 1.2.0 used and then the patch files to
be applied to it.  One of the files in there shows the order of the patch
files to be applied and I think they include relevant bug numbers and
descriptions.  I can get more details from the bugs if you'd like.

I can also e-mail it, but wasn't sure if cluttering the list with files was
appropriate.

AB


On Tue, Nov 6, 2012 at 10:51 AM, John Calcote <joh...@gm...>wrote:

> Aaron,****
>
> ** **
>
> Please send me the patches again if you can find them. I’ll look them over
> and see which ones are still applicable (haven’t been fixed yet, and the
> patch location still exists in a form to which the patch can be applied).*
> ***
>
> ** **
>
> --john****
>
> ** **
>
> *From:* Me [mailto:da...@gm...]
> *Sent:* Tuesday, November 06, 2012 10:38 AM
> *To:* OpenSLP Devel Mailing List
> *Subject:* Re: [Openslp-devel] 2.0 release imminent****
>
> ** **
>
> Once upon a time I posted the DIFFs from Novell for all of the openslp 1.x
> changes.  I know 2.x has had a ton of things rewritten, but since Novell
> had found/fixed all of those bugs has anybody who understands C been able
> to glance through those changes to ensure the problems are not present in
> the 2.x code?  If the code is needed again I can probably get access to the
> patch files and post them for whomever; I just hate to have bugs lingering
> when somebody else has already gone through the work of analyzing and
> fixing them in a way that may work out in 2.x as well as 1.x.****
>
> ** **
>
> On Tue, Nov 6, 2012 at 10:32 AM, Nick Wagner <ne...@wi...>
> wrote:****
>
> How do people feel about
> http://sourceforge.net/tracker/?func=detail&aid=1751139&group_id=1730&atid=101730?
>  I can take some time to look at it today before the release.
>  Unfortunately, I'm not in a location where I can easily look at the
> windows service deregister bug.****
>
> ** **
>
> --Nick****
>
> ** **
>
> ** **
>
> ** **
>
> On Tue, Nov 6, 2012 at 11:11 AM, John Calcote <joh...@gm...>
> wrote:****
>
> I’m about to create a 2.0 release of openslp – any issues we need to cover
> yet? Speak now or forever hold your peace. :)****
>
>  ****
>
> John****
>
> ** **
>
>
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> _______________________________________________
> Openslp-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openslp-devel****
>
> ** **
>
>
>
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> _______________________________________________
> Openslp-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openslp-devel****
>
> ** **
>

Re: [Openslp-devel] 2.0 release imminent

[John C. <joh...@gm...>]

Ok - please keep working on the tracker issue you mentioned - I'll take a
look at the windows service one.

 

John

 

From: nwa...@gm... [mailto:nwa...@gm...] On Behalf Of Nick
Wagner
Sent: Tuesday, November 06, 2012 11:05 AM
To: John Calcote
Cc: OpenSLP Devel Mailing List
Subject: Re: [Openslp-devel] 2.0 release imminent

 

Sorry, the tracker issue was for the SLP scope bug I'm looking at.  The
windows service dereg bug was the one Matthew brought up
<http://sourceforge.net/tracker/?func=detail&aid=3582209&group_id=1730&atid=
101730>
http://sourceforge.net/tracker/?func=detail&aid=3582209&group_id=1730&atid=1
01730

 

--Nick

 

On Tue, Nov 6, 2012 at 11:52 AM, John Calcote <joh...@gm...>
wrote:

Nick,

 

Are you sure you posted the correct reference? I don't see anything in that
tracker issue that's related to a windows service dereg bug. Or did you mean
to refer to this one an another one implied by a previous conversation?

 

Thanks,

John

 

From: nwa...@gm... [mailto:nwa...@gm...] On Behalf Of Nick
Wagner
Sent: Tuesday, November 06, 2012 10:32 AM
To: John Calcote
Cc: OpenSLP Devel Mailing List


Subject: Re: [Openslp-devel] 2.0 release imminent

 

How do people feel about http://sourceforge.net/tracker/?func=detail
<http://sourceforge.net/tracker/?func=detail&aid=1751139&group_id=1730&atid=
101730> &aid=1751139&group_id=1730&atid=101730?  I can take some time to
look at it today before the release.  Unfortunately, I'm not in a location
where I can easily look at the windows service deregister bug.

 

--Nick

 

 

 

On Tue, Nov 6, 2012 at 11:11 AM, John Calcote <joh...@gm...>
wrote:

I'm about to create a 2.0 release of openslp - any issues we need to cover
yet? Speak now or forever hold your peace. :)

 

John


----------------------------------------------------------------------------
--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________
Openslp-devel mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openslp-devel

 

 

Re: [Openslp-devel] 2.0 release imminent

[Nick W. <ne...@wi...>]

Sorry, the tracker issue was for the SLP scope bug I'm looking at.  The
windows service dereg bug was the one Matthew brought up
http://sourceforge.net/tracker/?func=detail&aid=3582209&group_id=1730&atid=101730

--Nick


On Tue, Nov 6, 2012 at 11:52 AM, John Calcote <joh...@gm...>wrote:

> Nick,****
>
> ** **
>
> Are you sure you posted the correct reference? I don’t see anything in
> that tracker issue that’s related to a windows service dereg bug. Or did
> you mean to refer to this one an another one implied by a previous
> conversation?****
>
> ** **
>
> Thanks,****
>
> John****
>
> ** **
>
> *From:* nwa...@gm... [mailto:nwa...@gm...] *On Behalf Of *Nick
> Wagner
> *Sent:* Tuesday, November 06, 2012 10:32 AM
> *To:* John Calcote
> *Cc:* OpenSLP Devel Mailing List
>
> *Subject:* Re: [Openslp-devel] 2.0 release imminent****
>
> ** **
>
> How do people feel about
> http://sourceforge.net/tracker/?func=detail&aid=1751139&group_id=1730&atid=101730?
>  I can take some time to look at it today before the release.
>  Unfortunately, I'm not in a location where I can easily look at the
> windows service deregister bug.****
>
> ** **
>
> --Nick****
>
> ** **
>
> ** **
>
> ** **
>
> On Tue, Nov 6, 2012 at 11:11 AM, John Calcote <joh...@gm...>
> wrote:****
>
> I’m about to create a 2.0 release of openslp – any issues we need to cover
> yet? Speak now or forever hold your peace. :)****
>
>  ****
>
> John****
>
>
>
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> _______________________________________________
> Openslp-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openslp-devel****
>
> ** **
>

Re: [Openslp-devel] 2.0 release imminent

[John C. <joh...@gm...>]

Nick,

 

Are you sure you posted the correct reference? I don't see anything in that
tracker issue that's related to a windows service dereg bug. Or did you mean
to refer to this one an another one implied by a previous conversation?

 

Thanks,

John

 

From: nwa...@gm... [mailto:nwa...@gm...] On Behalf Of Nick
Wagner
Sent: Tuesday, November 06, 2012 10:32 AM
To: John Calcote
Cc: OpenSLP Devel Mailing List
Subject: Re: [Openslp-devel] 2.0 release imminent

 

How do people feel about http://sourceforge.net/tracker/?func=detail
<http://sourceforge.net/tracker/?func=detail&aid=1751139&group_id=1730&atid=
101730> &aid=1751139&group_id=1730&atid=101730?  I can take some time to
look at it today before the release.  Unfortunately, I'm not in a location
where I can easily look at the windows service deregister bug.

 

--Nick

 

 

 

On Tue, Nov 6, 2012 at 11:11 AM, John Calcote <joh...@gm...>
wrote:

I'm about to create a 2.0 release of openslp - any issues we need to cover
yet? Speak now or forever hold your peace. :)

 

John


----------------------------------------------------------------------------
--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________
Openslp-devel mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openslp-devel

 

Re: [Openslp-devel] 2.0 release imminent

[John C. <joh...@gm...>]

Aaron,

 

Please send me the patches again if you can find them. I’ll look them over and see which ones are still applicable (haven’t been fixed yet, and the patch location still exists in a form to which the patch can be applied).

 

--john

 

From: Me [mailto:da...@gm...] 
Sent: Tuesday, November 06, 2012 10:38 AM
To: OpenSLP Devel Mailing List
Subject: Re: [Openslp-devel] 2.0 release imminent

 

Once upon a time I posted the DIFFs from Novell for all of the openslp 1.x changes.  I know 2.x has had a ton of things rewritten, but since Novell had found/fixed all of those bugs has anybody who understands C been able to glance through those changes to ensure the problems are not present in the 2.x code?  If the code is needed again I can probably get access to the patch files and post them for whomever; I just hate to have bugs lingering when somebody else has already gone through the work of analyzing and fixing them in a way that may work out in 2.x as well as 1.x.

 

On Tue, Nov 6, 2012 at 10:32 AM, Nick Wagner <ne...@wi...> wrote:

How do people feel about http://sourceforge.net/tracker/?func=detail <http://sourceforge.net/tracker/?func=detail&aid=1751139&group_id=1730&atid=101730> &aid=1751139&group_id=1730&atid=101730?  I can take some time to look at it today before the release.  Unfortunately, I'm not in a location where I can easily look at the windows service deregister bug.

 

--Nick

 

 

 

On Tue, Nov 6, 2012 at 11:11 AM, John Calcote <joh...@gm...> wrote:

I’m about to create a 2.0 release of openslp – any issues we need to cover yet? Speak now or forever hold your peace. :)

 

John

 

------------------------------------------------------------------------------
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________
Openslp-devel mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openslp-devel

 


------------------------------------------------------------------------------
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________
Openslp-devel mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openslp-devel

 

Re: [Openslp-devel] 2.0 release imminent

[Me <da...@gm...>]

Once upon a time I posted the DIFFs from Novell for all of the openslp 1.x
changes.  I know 2.x has had a ton of things rewritten, but since Novell
had found/fixed all of those bugs has anybody who understands C been able
to glance through those changes to ensure the problems are not present in
the 2.x code?  If the code is needed again I can probably get access to the
patch files and post them for whomever; I just hate to have bugs lingering
when somebody else has already gone through the work of analyzing and
fixing them in a way that may work out in 2.x as well as 1.x.


On Tue, Nov 6, 2012 at 10:32 AM, Nick Wagner <ne...@wi...> wrote:

> How do people feel about
> http://sourceforge.net/tracker/?func=detail&aid=1751139&group_id=1730&atid=101730?
>  I can take some time to look at it today before the release.
>  Unfortunately, I'm not in a location where I can easily look at the
> windows service deregister bug.
>
> --Nick
>
>
>
>
> On Tue, Nov 6, 2012 at 11:11 AM, John Calcote <joh...@gm...>wrote:
>
>> I’m about to create a 2.0 release of openslp – any issues we need to
>> cover yet? Speak now or forever hold your peace. :)****
>>
>> ** **
>>
>> John****
>>
>>
>> ------------------------------------------------------------------------------
>> LogMeIn Central: Instant, anywhere, Remote PC access and management.
>> Stay in control, update software, and manage PCs from one command center
>> Diagnose problems and improve visibility into emerging IT issues
>> Automate, monitor and manage. Do more in less time with Central
>> http://p.sf.net/sfu/logmein12331_d2d
>> _______________________________________________
>> Openslp-devel mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/openslp-devel
>>
>>
>
>
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> _______________________________________________
> Openslp-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openslp-devel
>
>

Re: [Openslp-devel] 2.0 release imminent

[Nick W. <ne...@wi...>]

How do people feel about
http://sourceforge.net/tracker/?func=detail&aid=1751139&group_id=1730&atid=101730?
 I can take some time to look at it today before the release.
 Unfortunately, I'm not in a location where I can easily look at the
windows service deregister bug.

--Nick




On Tue, Nov 6, 2012 at 11:11 AM, John Calcote <joh...@gm...>wrote:

> I’m about to create a 2.0 release of openslp – any issues we need to cover
> yet? Speak now or forever hold your peace. :)****
>
> ** **
>
> John****
>
>
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> _______________________________________________
> Openslp-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openslp-devel
>
>

[Openslp-devel] 2.0 release imminent

[John C. <joh...@gm...>]

I'm about to create a 2.0 release of openslp - any issues we need to cover
yet? Speak now or forever hold your peace. :)

 

John

Re: [Openslp-devel] Has anyone built a debian package before?

[John C. <joh...@gm...>]

Nick,

 

I've had a moment to verify the debian stuff to ensure I didn't lie to you
last week: :) The default prefix directory used by configure is /usr/local,
so all products get installed in this manner:

 

/

L-- usr

    L-- local

        +-- bin

        │   L-- slptool

        +-- etc

        │   +-- slp.conf

        │   +-- slp.reg

        │   L-- slp.spi

        +-- include

        │   L-- slp.h

        +-- lib

        │   +-- libslp.a

        │   +-- libslp.la

        │   +-- libslp.so -> libslp.so.1.0.0

        │   +-- libslp.so.1 -> libslp.so.1.0.0

        │   L-- libslp.so.1.0.0

        +-- sbin

        │   L-- slpd

        L-- var

            L-- log

 

But this is dumb, because neither /usr nor /usr/local have either an etc or
a var directory beneath them. I don't know why the autotools folks did this
- probably because they needed *some* root location to put things, and
/usr/local was as good as anywhere else, and it turns out that most things
should be installed relative to $prefix anyway. Additionally, developers
might not want to mix their dev package's etc entries with the system
entries when installing dev packages. Programs should be written to access
the $prefix variable as a command-line #define within source code, so they
know where to look for files normally found in /etc and /var.

 

However, system packages *do* want their version of packages' etc (or var)
contents mixed together in /etc (and /var), so they usually use a special
configure command that looks (for openslp anyway) something like this:

$ ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var

 

Which leaves the installed files in a tree like this:

 

/

+-- etc

│   +-- slp.conf

│   +-- slp.reg

│   L-- slp.spi

+-- usr

│   +-- bin

│   │   L-- slptool

│   +-- include

│   │   L-- slp.h

│   +-- lib

│   │   +-- libslp.a

│   │   +-- libslp.la

│   │   +-- libslp.so -> libslp.so.1.0.0

│   │   +-- libslp.so.1 -> libslp.so.1.0.0

│   │   L-- libslp.so.1.0.0

│   L-- sbin

│       L-- slpd

L-- var

    L-- log

 

Thus, the debian or redhat init scripts can refer to slpd as /usr/sbin/slpd.
Although it's still much better to generate the init scripts from the
configure variables at configure or make time so they get changed
appropriately if different arguments are used. We don't actually supply a
debian init script in our package, so the init script is coming from
elsewhere (some system packager, perhaps?).

 

John

 

From: Nick Wagner [mailto:ne...@wi...] 
Sent: Thursday, October 25, 2012 10:17 AM
To: ope...@li...
Subject: [Openslp-devel] Has anyone built a debian package before?

 

I took a quick look at the Debian start-stop script, and it does need to use
the -p  option when running slpd.  But then I noticed that it was still
referring to /usr/sbin/slpd, when I believe we now install to
/usr/local/bin.  Do we need to make the start-stop script use the new
directory?  do we need to change the whole debian subdirectory in
openslp.misc?

 

--Nick

Re: [Openslp-devel] slptool hangs on AIX?

[Jim M. <jim...@wb...>]

Are there any other changes that are being waited on? I've run our tests 
and they all work, so I would like to propose we roll out 2.0.

Thanks

John Calcote wrote:
>
> Fixed in revision 1693 -- SLP atomics now return the correct (new) 
> value on AIX.
>
> John
>
> *From:*John Calcote [mailto:joh...@gm...]
> *Sent:* Tuesday, October 30, 2012 12:14 PM
> *To:* Jim Marshall
> *Cc:* ope...@li...
> *Subject:* Re: [Openslp-devel] slptool hangs on AIX?
>
> Hi Jim,
>
> On Tue, Oct 30, 2012 at 10:54 AM, Jim Marshall 
> <jim...@wb... 
> <mailto:jim...@wb...>> wrote:
>
> Hi,
>  Been testing the AIX build I have and the agent is working fine but 
> when I invoke slptool it basically hangs. Stepping into the code we 
> get to libslp_handle.c line 66
>
> if (SLPAtomicInc(&s_OpenSLPHandleCount) == 1)
>
> The SLPAtomicInc function does this on AIX:
>
> return (intptr_t)fetch_and_add((atomic_p)pn, 1);
>
> This is the cause of the hang, because fetch_and_add "[...] returns 
> the original value of the variable" (from the man page), in this case 
> '0'. When this happens the code enters a while loop
>
> Well, that's kind of useless, isn't it? It should be replaced with:
>
>    return (intptr_t)fetch_and_add((atomic_p)pn, 1) + 1;
>
> The idea here is to atomically increment the value stored at pn. If 
> two threads try to do it at once, then they could both read the value, 
> increment it and both write the same value back out. The use of 
> atomic_add should cause both threads to actually increment the value, 
> regardless of how in-sync they are on their attempts to update the value.
>
> It's only a side-effect (that we take advantage of) that most atomic 
> incs return the newly updated value. Since the AIX version returns the 
> original value, and we're guaranteed to read/update/write atomically 
> when we add 1 to that original value, then we can assume that the 
> value we get back PLUS ONE is our actual desired return value.
>
> I'll fix it.
>
> John
>


-- 
mail
Jim Marshall

Sr. Software Engineer
WS <http://ws-inc.com/>

Re: [Openslp-devel] slptool hangs on AIX?

[John C. <joh...@gm...>]

Fixed in revision 1693 - SLP atomics now return the correct (new) value on
AIX.

 

John

 

From: John Calcote [mailto:joh...@gm...] 
Sent: Tuesday, October 30, 2012 12:14 PM
To: Jim Marshall
Cc: ope...@li...
Subject: Re: [Openslp-devel] slptool hangs on AIX?

 

Hi Jim,

On Tue, Oct 30, 2012 at 10:54 AM, Jim Marshall
<jim...@wb...> wrote:

Hi,
 Been testing the AIX build I have and the agent is working fine but when I
invoke slptool it basically hangs. Stepping into the code we get to
libslp_handle.c line 66

if (SLPAtomicInc(&s_OpenSLPHandleCount) == 1)

The SLPAtomicInc function does this on AIX:

return (intptr_t)fetch_and_add((atomic_p)pn, 1);

This is the cause of the hang, because fetch_and_add "[...] returns the
original value of the variable" (from the man page), in this case '0'. When
this happens the code enters a while loop

 

 

Well, that's kind of useless, isn't it? It should be replaced with:

 

   return (intptr_t)fetch_and_add((atomic_p)pn, 1) + 1;

 

The idea here is to atomically increment the value stored at pn. If two
threads try to do it at once, then they could both read the value, increment
it and both write the same value back out. The use of atomic_add should
cause both threads to actually increment the value, regardless of how
in-sync they are on their attempts to update the value.

 

It's only a side-effect (that we take advantage of) that most atomic incs
return the newly updated value. Since the AIX version returns the original
value, and we're guaranteed to read/update/write atomically when we add 1 to
that original value, then we can assume that the value we get back PLUS ONE
is our actual desired return value.

 

I'll fix it.

 

John

Re: [Openslp-devel] slptool hangs on AIX?

[John C. <joh...@gm...>]

Hi Jim,

On Tue, Oct 30, 2012 at 10:54 AM, Jim Marshall <
jim...@wb...> wrote:

>  Hi,
>  Been testing the AIX build I have and the agent is working fine but when
> I invoke slptool it basically hangs. Stepping into the code we get to
> libslp_handle.c line 66
>
> if (SLPAtomicInc(&s_OpenSLPHandleCount) == 1)
>
> The SLPAtomicInc function does this on AIX:
>
> return (intptr_t)fetch_and_add((atomic_p)pn, 1);
>
> This is the cause of the hang, because fetch_and_add "[...] returns the
> original value of the variable" (from the man page), in this case '0'. When
> this happens the code enters a while loop
>


Well, that's kind of useless, isn't it? It should be replaced with:

   return (intptr_t)fetch_and_add((atomic_p)pn, 1) + 1;

The idea here is to atomically increment the value stored at pn. If two
threads try to do it at once, then they could both read the value,
increment it and both write the same value back out. The use of atomic_add
should cause both threads to actually increment the value, regardless of
how in-sync they are on their attempts to update the value.

It's only a side-effect (that we take advantage of) that most atomic incs
return the newly updated value. Since the AIX version returns the original
value, and we're guaranteed to read/update/write atomically when we add 1
to that original value, then we can assume that the value we get back PLUS
ONE is our actual desired return value.

I'll fix it.

John

[Openslp-devel] slptool hangs on AIX?

[Jim M. <jim...@wb...>]

Hi,
  Been testing the AIX build I have and the agent is working fine but 
when I invoke slptool it basically hangs. Stepping into the code we get 
to libslp_handle.c line 66

if (SLPAtomicInc(&s_OpenSLPHandleCount) == 1)

The SLPAtomicInc function does this on AIX:

return (intptr_t)fetch_and_add((atomic_p)pn, 1);

This is the cause of the hang, because fetch_and_add "[...] returns the 
original value of the variable" (from the man page), in this case '0'. 
When this happens the code enters a while loop

       while (!s_HandlesInitialized)
          sleep(0);

The only way I can work around this is to remove the "#define 
USE_AIX_ATOMICS" (line 137 of slp_atomics.c).

This code has been in OpenSLP for a long time (Aug 2006), so I am 
wondering if this is working for others? And if so, how?

Thank you
-- 
mail
Jim Marshall

Sr. Software Engineer
WS <http://ws-inc.com/>

[Openslp-devel] AIX patches

[Jim M. <jim...@wb...>]

Index: configure.ac
===================================================================
--- configure.ac	(revision 1692)
+++ configure.ac	(working copy)
@@ -54,6 +54,11 @@
 #
 # Checks for structure members
 #
+AC_CHECK_MEMBER([struct sockaddr_storage.ss_family],
+	[AC_DEFINE(HAVE_SOCKADDR_STORAGE_SS_FAMILY,1,[whether sockaddr_storage 
+has ss_family])],
+        [], [#include <sys/socket.h>])
+
 AC_CHECK_MEMBER([struct sockaddr_in.sin_len],
 	[AC_DEFINE(HAVE_SOCKADDR_IN_SIN_LEN,1,[whether sockaddr_in has sin_len])],
 	[], [#include <netinet/in.h>])

Re: [Openslp-devel] Building issues on AIX

[Ian N. <in...@gm...>]

Turns out we build on aix 5.3 but we use the xlc_r compiler instead of gcc.
On 25 Oct 2012 17:07, "Ian Norton" <in...@gm...> wrote:

> We build the 2.0 beta sources, ill see if i can find if we do anything
> different.
> On 25 Oct 2012 16:56, "Jim Marshall" <jim...@wb...>
> wrote:
>
>>  Has anyone built the current OpenSLP on AIX?  If so what version?
>>
>> We have AIX 6.1 and the first issue we ran  into was in common/slp_net.h
>> line 75
>>
>> # define ss_family                   __ss_family
>>
>> it appears with AIX 6 they have changed to use 'ss_family' so you get a
>> compile error on __ss_family, easy enough fix tho.
>>
>> The major issue I am running into appears to be with the flex/bison
>> stuff. Here is the output of the build
>>
>>  gcc -DHAVE_CONFIG_H -I. -I. -I.. -DAIX -maix64 -Wall -O3 -MT
>> slp_filter_l.lo -MD -MP -MF .deps/slp_filter_l.Tpo -c slp_filter_l.c  -DPIC
>> -o .libs/slp_filter_l.o
>> slp_filter_l.l: In function 'filter_close_lexer':
>> slp_filter_l.l:174: warning: cast to pointer from integer of different
>> size
>> slp_filter_l.l: In function 'slp_filter_init_lexer':
>> slp_filter_l.l:181: warning: cast from pointer to integer of different
>> size
>> /bin/sh ../ylwrap slp_attr_y.y y.tab.c slp_attr_y.c y.tab.h slp_attr_y.h
>> y.output slp_attr_y.output -- bison -y  -d
>> /usr/bin/m4: Not a recognized flag: -
>> Usage: m4 [-els] [-B Number] [-D Name[=Value]]... [-H Number]
>>        [-I Directory] [-S Number] [-T Number] [-U Name]... [File...]
>> make[2]: *** [slp_attr_y.c] Error 1
>>
>>
>> we have the following installed:
>> flex version 2.5.4
>> bison (GNU Bison) 2.6.2
>> m4 (GNU M4) 1.4.16
>>
>>
>> I don't seem to see the 'yywrap' call on Linux, so I am wondering if
>> there is some tool I am missing?
>>
>> Thank you
>>
>> --
>> Jim Marshall
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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-devel mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/openslp-devel
>>
>>

[Openslp-devel] [PATCHv2] semi-automatically refresh listening interfaces

[Gavin L. <ga...@co...>]

I've attached a variation of the previous patch (still against the 2.0 beta
2 tarball) which handles the reinit slightly differently from the original.

This one will start listening on any newly discovered (or configured)
interfaces, without closing or stopping any previously opened incoming
sockets.

The advantage over the previous patch is that it will cause less disruption
to ongoing communications, particularly if only a secondary interface is
changing.  The disadvantage is that if the service is left running for a
long time on a network that keeps assigning it different addresses
(presumably via a DHCP server with a bad memory) then it will gradually eat
up more and more resources, and probably eventually fail.  (I'm not sure
which tradeoff is better overall.)

A suggested improvement (which again I'm not quite familiar enough with the
code to do at this point) would be to track which sockets are associated
with a particular interface and close them if their interface is not still
present during the reinit.

Note that for code simplicity it's currently assuming that if the TCP listen
socket exists then all the other related sockets are still ok too.

Re: [Openslp-devel] Has anyone built a debian package before?

[Gavin L. <ga...@co...>]

Quoth Nick Wagner:
> I took a quick look at the Debian start-stop script, and it does need to
use the -p
> option when running slpd.  But then I noticed that it was still referring
to 
> /usr/sbin/slpd, when I believe we now install to /usr/local/bin.  Do we
need to 
> make the start-stop script use the new directory?  do we need to change
the whole 
> debian subdirectory in openslp.misc?

The Debian packaging rules specify that it's illegal for a prebuilt package
to install to /usr/local (that's reserved for manual built-from-source
programs).  So presumably somewhere in the "make a package" scripts it will
be explicitly changing the prefix.

Re: [Openslp-devel] Has anyone built a debian package before?

[John C. <joh...@gm...>]

The script should be generated during configure/make to use the $(prefix)
variable so that the script starts and stops slpd wherever it ends up. I'll
take a look at it as soon as I can - probably in the next day or two.

 

John

 

From: Nick Wagner [mailto:ne...@wi...] 
Sent: Thursday, October 25, 2012 10:17 AM
To: ope...@li...
Subject: [Openslp-devel] Has anyone built a debian package before?

 

I took a quick look at the Debian start-stop script, and it does need to use
the -p  option when running slpd.  But then I noticed that it was still
referring to /usr/sbin/slpd, when I believe we now install to
/usr/local/bin.  Do we need to make the start-stop script use the new
directory?  do we need to change the whole debian subdirectory in
openslp.misc?

 

--Nick

[Openslp-devel] Has anyone built a debian package before?

[Nick W. <ne...@wi...>]

I took a quick look at the Debian start-stop script, and it does need to
use the -p  option when running slpd.  But then I noticed that it was still
referring to /usr/sbin/slpd, when I believe we now install to
/usr/local/bin.  Do we need to make the start-stop script use the new
directory?  do we need to change the whole debian subdirectory in
openslp.misc?

--Nick

Re: [Openslp-devel] Building issues on AIX

[Ian N. <in...@gm...>]

We build the 2.0 beta sources, ill see if i can find if we do anything
different.
On 25 Oct 2012 16:56, "Jim Marshall" <jim...@wb...> wrote:

>  Has anyone built the current OpenSLP on AIX?  If so what version?
>
> We have AIX 6.1 and the first issue we ran  into was in common/slp_net.h
> line 75
>
> # define ss_family                   __ss_family
>
> it appears with AIX 6 they have changed to use 'ss_family' so you get a
> compile error on __ss_family, easy enough fix tho.
>
> The major issue I am running into appears to be with the flex/bison stuff.
> Here is the output of the build
>
>  gcc -DHAVE_CONFIG_H -I. -I. -I.. -DAIX -maix64 -Wall -O3 -MT
> slp_filter_l.lo -MD -MP -MF .deps/slp_filter_l.Tpo -c slp_filter_l.c  -DPIC
> -o .libs/slp_filter_l.o
> slp_filter_l.l: In function 'filter_close_lexer':
> slp_filter_l.l:174: warning: cast to pointer from integer of different size
> slp_filter_l.l: In function 'slp_filter_init_lexer':
> slp_filter_l.l:181: warning: cast from pointer to integer of different size
> /bin/sh ../ylwrap slp_attr_y.y y.tab.c slp_attr_y.c y.tab.h slp_attr_y.h
> y.output slp_attr_y.output -- bison -y  -d
> /usr/bin/m4: Not a recognized flag: -
> Usage: m4 [-els] [-B Number] [-D Name[=Value]]... [-H Number]
>        [-I Directory] [-S Number] [-T Number] [-U Name]... [File...]
> make[2]: *** [slp_attr_y.c] Error 1
>
>
> we have the following installed:
> flex version 2.5.4
> bison (GNU Bison) 2.6.2
> m4 (GNU M4) 1.4.16
>
>
> I don't seem to see the 'yywrap' call on Linux, so I am wondering if there
> is some tool I am missing?
>
> Thank you
>
> --
> Jim Marshall
>
>
>
> ------------------------------------------------------------------------------
> 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-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openslp-devel
>
>

[Openslp-devel] Building issues on AIX

[Jim M. <jim...@wb...>]

Has anyone built the current OpenSLP on AIX?  If so what version?

We have AIX 6.1 and the first issue we ran  into was in common/slp_net.h 
line 75

# define ss_family                   __ss_family

it appears with AIX 6 they have changed to use 'ss_family' so you get a 
compile error on __ss_family, easy enough fix tho.

The major issue I am running into appears to be with the flex/bison 
stuff. Here is the output of the build

  gcc -DHAVE_CONFIG_H -I. -I. -I.. -DAIX -maix64 -Wall -O3 -MT 
slp_filter_l.lo -MD -MP -MF .deps/slp_filter_l.Tpo -c slp_filter_l.c  
-DPIC -o .libs/slp_filter_l.o
slp_filter_l.l: In function 'filter_close_lexer':
slp_filter_l.l:174: warning: cast to pointer from integer of different size
slp_filter_l.l: In function 'slp_filter_init_lexer':
slp_filter_l.l:181: warning: cast from pointer to integer of different size
/bin/sh ../ylwrap slp_attr_y.y y.tab.c slp_attr_y.c y.tab.h slp_attr_y.h 
y.output slp_attr_y.output -- bison -y  -d
/usr/bin/m4: Not a recognized flag: -
Usage: m4 [-els] [-B Number] [-D Name[=Value]]... [-H Number]
        [-I Directory] [-S Number] [-T Number] [-U Name]... [File...]
make[2]: *** [slp_attr_y.c] Error 1


we have the following installed:
flex version 2.5.4
bison (GNU Bison) 2.6.2
m4 (GNU M4) 1.4.16


I don't seem to see the 'yywrap' call on Linux, so I am wondering if 
there is some tool I am missing?

Thank you

-- 
mail
Jim Marshall

[Openslp-devel] Building on Solaris

[Jim M. <jim...@wb...>]

Hi,
  We've got OpenSLP building and running on Sparc Solaris, we built it 
using GCC. My question revolves around the dependency of libgcc_s.so.1 
when built this way, it would be preferable if we could build it so that 
it did not have that dependency. Just wondering if anyone out there may 
have some thoughts on if this is possible and if so how?

I've tried various gcc and configure options (for example 
--static-libgcc, -nostdlib -lc, etc).

Thanks

-- 
mail
Jim Marshall

[Openslp-devel] Solaris 10 sparn, issue with signal.h

[Jim M. <jim...@wb...>]

We got our Sparc machine up and running but when we ran configure we got 
the following warning:

checking signal.h presence... yes
configure: WARNING: signal.h: present but cannot be compiled
configure: WARNING: signal.h:     check for missing prerequisite headers?
configure: WARNING: signal.h: see the Autoconf documentation
configure: WARNING: signal.h:     section "Present But Cannot Be Compiled"
configure: WARNING: signal.h: proceeding with the preprocessor's result
configure: WARNING: signal.h: in the future, the compiler will take 
precedence



If you continue and try to run make you end up with an error message 
that is like this

In file included from /usr/include/sys/signal.h:34,
                  from /usr/include/signal.h:26,
/usr/include/sys/siginfo.h:259: error: parse error before "ctid_t"
/usr/include/sys/siginfo.h:292: error: parse error before '}' token
/usr/include/sys/siginfo.h:294: error: parse error before '}' token


We're using gcc 3.3.2 (I know, it's old) and the solution (after much 
googling) is pretty simple. What I read seems to imply it maybe specific 
to gcc 3.3.2 on Solaris. Here is the solution

cd /usr/local/lib/gcc-lib/sparc-sun-solaris2.10/3.3.2/install-tools
./mkheaders


-- 
mail
Jim Marshall

[Openslp-devel] Code Freeze

[Jim M. <jim...@wb...>]

Hi,
  Per my earlier email (10/12/2012 12:15 PM) I would like to do a code 
freeze on the tree (svn version 1692).

We've done testing on Centos 5.5 and Windows 7 and things appear to be 
working fine (mixing 32bit slpd and 64bit slptool and vice-versa, also 
using older 1.x slpd and slptool)

I believe that the 'hijacking' issue was resolved and tested.

We are having issues with building on Solaris at the moment (a gcc issue 
right now) but will test on that and AIX this week.

Thank you
-- 
mail
Jim Marshall

Sr. Software Engineer
WS <http://ws-inc.com/>

Re: [Openslp-devel] [Openslp-users] slpd seems to hijack the port I'm using in my application

[Robert H. <rh...@hs...>]

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
>
>
>