you mean to say when you start bot with '-n' it works fine and without '-n' it wont work? (i.e. as mention in the very first post that "without -n it does nothing, no telnet, no connection to irc server")
I'm an idiot, At least this one [bug] took about 5 minutes to find...
right now my bot is sitting in my channel doing everything it should do but to achieve that I have it running in a second console that I can't close or the bot quits.
without the -n it start' without errors but no connections at all in or out
I did a test myself today and started a bot with the -n switch, closed the the Telnet session (SecureCRT) and the bot remained connected to the Network and functioned as expected.; in fact it's still connected after 5 hrs.
Your problem, going by my test, therefore has nothing to do with eggdrop in my opinion.
Add [SOLVED] to the thread title if your issue has been. Search | FAQ | RTM
ok so you can detach from a telnet session without the session fully terminating. great
but it still does not change the fact that when I run the bot and I Don't use the -n switch which is the correct way to run the bot it does not work.
I don't want it running in a second console with the -n switch on so it is outputing everything to the screen I want it to run in the background like it is supposed to.
I can run it in a screen session with the -n switch and detach from the screen which is effectivly the same thing you are doing just a different way.
However doing it this way I cannot use the botcheck script to make sure the bot is running and restart it if it crashes.
as the message says, report this bug (not that someone would bother anyway, they hadn't released a new version for ages and I doubt anyone's working on fixing bugs)
connection, sharing, dcc problems? click <here>
before asking for scripting help, read <this>
use
I just helped a sysadmin tracking down the background problem. It seems this because of version missmatching of TCL. Thinking of the nature of the error its no wonder installing and using TCL 8.3 also solves the problem, but thats strictly seen a workaround and no solution.
However I found out that there were 2 TCL versions installed, one in /usr/lib and one in /usr/local/lib. the one in /usr/lib had no header files, version was 8.4.9 and was configured as threaded. In /usr/local/lib there was 8.4.12 configured as non-threaded and with header files. However the configure script detected the TCL in /usr/local/lib, found its headers and compiled. But the system checked the libary first in /usr/lib and ran a non-threaded eggdrop on an old threaded TCL.
Solution A: (the user solution)
use 'export LD_LIBRARY_PATH=/usr/local/lib' to point to the libarary that the bot actually is compiled with. Use the configure --with-tcllib= and --with-tclinc= switchs to change which TCL eggdrop is compiled with.
Solution B: (the root solution)
locate and delete the second TCL installation and preferable install it into the system default prefix (which is /usr and not /usr/local for debian as example). 'whereis tcl' or 'locate tcl8.4' might help you finding duplicates.
PS: no garantue every background connect failure is related to this, but it likely is the main reason. If people can confirm this solution it might be added to the FAQ ^-^.
Last edited by De Kus on Sat Dec 31, 2005 5:56 pm, edited 3 times in total.
this is no solution for the crash, but for the original topic which is about eggdrop working in foreground but fails to handle network connections in background. Same problem occured in tclsh so I tried to track it down, since I knew it was sure it must be because of TCL.