The warning message is found in tdelibs/tdecore/ksock.cpp.

In ksock.cpp is the following comment:

// on Linux/libc5, this includes linux/socket.h where SOMAXCONN is defined

As far as I can tell on my Slackware 14.0 system, SOMAXCONN is not defined in socket.h but in /usr/include/bits/socket.h, which is installed by glibc.

I hit the Submit button too soon.

linux/socket.h contains the following:

#include <bits/socket.h>

I don't see this message when testing the latest GIT sources on Linux (Debian Jessie).

Did the message appear in the first user's session log or in the session log of the new user?

Was there any additional information that might help pinpoint the application spewing the message?  A full ~/.xsession_errors log attached to this report would help here.

Thanks!

>Did the message appear in the first user's session log or in the session log of
>the new user?
New user.

>Was there any additional information that might help pinpoint the application 
>spewing the message?
Possibly bug 1713, comment 4 (http://bugs.pearsoncomputing.net/show_bug.cgi?id=1713#c4).

I am still unable to replicate this on my Linux system.

Can you post an example ~/.xsession_errors file for a new user illustrating the problem?

Thanks!

Created attachment 2259 [details]
xsession-errors

Look at lines 105, 107.

The -1 is not a reference to the $DISPLAY environment variable, as I tested with three users and both the second and third user displayed the same error message. Seems the -1 reference is something else. I see the same error message even when logging as root as the second user.

I never see the error in the first user's log.

I use the $TMP, $TEMP, and $TMPDIR environment variables, which are pointed to tmpfs in RAM. Thus each user's $TDEDIR/socket-$HOSTNAME and $TDEDIR/tmp-$HOSTNAME are stored in RAM rather than a hard-coded /tmp. I don't know whether that plays a role.

Created attachment 2260 [details]
Debug ksock

Thanks for the log.  Can you apply the attached debugging patch to tdelibs and generate a new log with it installed?  This will help me narrow down the exact application causing this.

Thanks!

>Can you apply the attached debugging patch to tdelibs and generate a new log
>with it installed?
Downloaded. Probably will be a while before I get to this.

Created attachment 2276 [details]
First xsession-errors log with ksocket debug patch

I don't see anything revealing. Original error message begins at line 130 in attached log.

(In reply to Darrell from comment #9)
> Created attachment 2276 [details]
> First xsession-errors log with ksocket debug patch
> 
> I don't see anything revealing. Original error message begins at line 130 in
> attached log.

Yeah unfortunately it looks like we hit a bug in the __progname implementation.  However, on close inspection, at least it should be narrowed down to these possibilities:

artswrapper
kaccess
notification-daemon-tde
kmixctrl
/usr/local/bin/run_conky
/bin/sh
kalarmd
release_notes
kmix

So we're looking for the two culprits from that list.  We can likely discount the following applications as I run them on my test box and cannot seem to trigger the error message:
kaccess
kmix

My initial suspects are (primarily because I have no way to test them!):
/usr/local/bin/run_conky
/bin/sh
release_notes

Can you try disabling applications in the uppermost list until the first two error messages go away?  I would trace this further if I could replicate it, but until we know the application at fault I have little to no chance of doing so.

Thanks!

Tim

This took a long while to isolate. The cause is the TDE Internet Daemon. To view:

* In KControl->TDE Components->Service Manager, stop the TDE Internet Daemon.
* tail -f ~/.xsession-errors
* Start the TDE Internet Daemon.

Repeat starting/stopping as much as desired.

(In reply to Darrell from comment #11)
> This took a long while to isolate. The cause is the TDE Internet Daemon. To
> view:
> 
> * In KControl->TDE Components->Service Manager, stop the TDE Internet Daemon.
> * tail -f ~/.xsession-errors
> * Start the TDE Internet Daemon.
> 
> Repeat starting/stopping as much as desired.

Thanks for tracking that down for me!  I do not have the TDE Internet Daemon installed on my system, which explains why I did not see the message.

As you probably well know the more stuff I install on my development machine the harder it is to check for build failures and such while maintaining a consistent package set due to the vastly increased compilation time.  This is the reason I occasionally have issues reproducing items like this, so your help here was much appreciated.

I'll get on this as soon as I finish with the bug I am currently working on.

The daemon is from tdenetwork, in the krdc directory. Thus BUILD_KRFB needs to be enabled to build kinetd.

I can finally reproduce this.  In addition to the above conditions, krfb desktop sharing must be enabled with automatic port selection on both sessions.

The message probably comes from the code detecting which ports are available.  I'll try to get a fix out shortly.

Fixed in GIT hashes 67d3c30 (tdelibs) and fa1a997 (tdenetwork).

Thanks for reporting, and for tracking down the offending service!

the original mesages no longer appear. I have not yet rebuilt tdenetwork. I now see the following messages:

tdecore (KNetwork socket): WARNING: Error listening on socket for port 5800: -1
tdecore (KNetwork socket): WARNING: Error listening on socket for port 5900: -1

I presume by the description of commit fa1a997a (tdenetwork) that such messages are now silenced. Is that the intent and a good idea? Seems here there is an error that is not resolved?

(In reply to Darrell from comment #16)
> the original mesages no longer appear. I have not yet rebuilt tdenetwork. I
> now see the following messages:
> 
> tdecore (KNetwork socket): WARNING: Error listening on socket for port 5800:
> -1
> tdecore (KNetwork socket): WARNING: Error listening on socket for port 5900:
> -1
> 
> I presume by the description of commit fa1a997a (tdenetwork) that such
> messages are now silenced. Is that the intent and a good idea? Seems here
> there is an error that is not resolved?

Yes that is the intent, and yes it's a good idea. ;-)

The krfb service finds a free port in the recommended manner--binding to each port in sequence until the bind succeeds.  There is no other way to check if a port is free without introducing serious race conditions.  Therefore, in this one case, binding errors are not only OK but expected--my patches simply silence them.

If you look at the documentation changed in the tdelibs commit you will see my warning message there.  The idea is yes, you can silence the bind errors, but if you do so you take on all the risks and responsibilities, including printing an error message if your autoscan routine fails to open any port in the end.  The krfb code already does that, so the individual bind errors can be safely silenced.

I hope this helps!