I just installed Fedora Core 6 and eggdrop (latest version).
I tryed to start it with ./eggdrop -m eggdrop.conf but although the process stays active and it says the eggdrop has started, he doesn't show up on IRC.
I killed that process and tryed again, but this time the same command only -n added in the end. I can see the things getting activated, I can see the eggdrop connectin... and I check on IRC, he is there. EVERYTIME I start it with -n option, he shows up on IRC. Without it never shows up.
What is the cause of my problem and how can I fix it please?
This is actually is a serious problem that I have too and I do have a log file and it says:
Writting Userfile
Writting Channel File
and than when i kill it it add something with TERMSIGNAL.
as ljesh already says in -n it shows up. There is a solution with the -n option you can run it with -n in background but its a very crappy solution. This is how i do it
It seems like these problems are happening on Fedora, so far only Fedora has been mentioned as the operating system.
If so, you may want to look at using a different operating system.
I'm running 1.6.18 without any issues under FC4 (Stentz) using tcl8.4.9-3.
This version (of tcl), however, is not threaded or linked against libpthread.
Also, downloaded the .srpm's for FC5 and FC6, and it would seem from the changelog that threads was enabled as of 8.4.12-4.
One option on these systems would be to download the source-rpm, modify the .spec-file (look for a line containing --enable-threads), and rebuild the rpm-package.
Threaded TCL works fine on all my FreeBSD machines, so this problem with threaded TCL may just be with Fedora (and derivatives)?
Or is this a problem with most GNU systems?
After digging through the source abit, it would seem it might be an issue where the configure-scripts fail to properly detect that the tcl-libraries are thread-enabled on these platforms.
Downloading the source and compiling manually would work just fine, with the only exception/issue that rpm might have some issues solving dependancies (which can be overridden).
There is still the option of building your own rpm's using a custom .spec-file, which allows you to compile it to your likes while preserving rpm-dependancies.
And this makes a great example of why I love FreeBSD's ports.
"To each their own." as the saying goes. Hopefully the RPM makers will fix it for the GNU communities that use them.