[collectd] 4.2.1 on Solaris 10

[Christophe Kalt]

On Dec 05, Florian Forster wrote:
| thanks again for your bugreports :)

No problem, thanks for the work :-)

| That those plugins aren't disabled by default kind of sucks. Apparently
| Solaris is not Solaris, though: I compile collectd on a Solaris box from
| time to time (yes, it's Solaris 10 there, too) and there the apcups
| plugin (with that _FILE_OFFSET_BITS problem) and the swap plugin worked
| there without a problem. It'd be interesting what the differences are: I
| used the Sun CC and it was a SPARC machine. Is there more that sets
| Solaris installations apart?

Sigh, hate these! :-)
Solaris x86 w/ gcc for me, although i have SPARC as well, and
Sun Studio 10/11/12 (as does everyone these days, i think).

| Solaris doesn't usually define the standard getpwnam_r for whatever
| reason. Probably an autoconf check and/or some C magic would be
| appropriate. For now you can force Solaris to define a standard
| compliant version of getpwnam_r with the `_POSIX_PTHREAD_SEMANTICS'
| or by defining `_POSIX_C_SOURCE' greater than or equal to 199506.

Solaris gives you the choice between various standards, it's a
matter of picking something the right define indeed.  This
stuff is well documented in standards(5).

| On Wed, Dec 05, 2007 at 03:36:33PM -0500, Christophe Kalt wrote:
| > But other things compile just fine, so saying that it's an autoconf
| > bug may be a bit premature.
| 
| collectd itself doesn't define `_FILE_OFFSET_BITS' anywhere and there's
| that LFS macro that does some magic. The autotools would be the first
| place where I'd think the problem comes from, too..

right, autoconf defines it for you.

| > | D'oh... a lot of those *_r functions seem to be quite system-dependent.
| 
| No, actually they're in one of the POSIX versions. The (GNU) manpage of
| getgrnam_r on my workstation talks about POSIX.1-2001, but the define
| (see above) seems to refer to an earlier version..
| 
| > Easy, it calls swapctl(2); but unlike collectd, swap(1M) does not also
| > need LFS support.
| 
| Probably some struct has a member of type off_t which is redefined by
| those autoconf macros or something. I'm pretty sure that this can be
| fixed by some more magic in the swap plugin.. I'll see what I can find
| out..

No.. autoconf #defines just trigger this in the OS include
files.  On Solaris, lf64(5) and company explain this.
i don't expect you can fix it, other by sacrificing LFS.
May be my original mail lacked clarity, here are lines from
<sys/swap.h>:

#if !defined(_LP64) && _FILE_OFFSET_BITS == 64
#error  "Cannot use swapctl in the large files compilation environment"
#endif

In other words, if you have LFS, you can't have swapctl(2)

Well, now that i think about it a bit more, there's another
solution, but not one i find especially appealing either
unless you're ready to commit to the effort it'll take.
Build a 64 bit binary.

| > My quick read of the collectd 4 docs seem to indicate the latter can
| > easily be achieved with the exec and unixsock plugins, but what i was
| > saying is that it'd be nicer if collectd did that transparently.
| 
| I see the popularity of the exec plugin with mixed feelings: Sure it's
| nice that everyone can hack some script in whatever language he feels
| like today, but collectd's goal is not rapid development but well
| written and maintainted functionality. So I'd rather spend two days
| looking at how to make the swap plugin work with the LFS stuff (or how
| to tell autoconf that you system doesn't need it at all) then take ten
| minutes to write that simple wrapper around `swap -s'.

That's why i wrote you about this.  I'd prefer if you did it
right as well :-)

| So, the bottom line is: Thank you very much for your bugreports, I'll do
| my best to resolve the problems. The `getgrnam_r' functions (and
| friends) will be ``blessed'' with an own autoconf check in the next
| minor version or the next patch release, I'm not sure yet. The problems
| in the apcups and swap plugins both seem to be LFS related. I'll have to
| see if that behavior is expected and how it can be fixed or worked
| around. My suspicion is that LFS is activated although it's not needed
| under Solaris.

LFS is needed, or collectd can't handle >2TB filesystems.
My old 3.9.3 install doesn't have LFS and as a result, i don't
have any data on my larger filesystems.