unable to compile recent adchpp builds on linux

[Vinay Dargar]

Hi. I've been trying to run a adchpp hub (migrating from ptokax).
The provided Windows binaries for the latest version 2.12.1 works fine, but compiling the source for this newest version on linux fails.
I've tried compiling on Ubuntu 14.04/16.04 x64 (inbuilt in windows 10 bash-on-windows), on Debian Jessie x64, and Raspbian Jessie on my raspberry pi 2B (arm). I referred to this question posted 3-4 years ago https://answers.launchpad.net/adchpp/+question/236015
which provided the info to remove the two lines in SConstruct to get the build compiling.

However the binary generated does not run correctly:

adchpp_2.12.1_source/build/debug-default-x64/bin] ./adchppd
Starting.
Core initialized
.Thrown: FileException: Could not open file
Unable to load adchpp.xml, using defaults: FileException: Could not open file
.
2.12.1 (r"[unknown]") Debug running, press ctrl-c to exit...
Logging: 2017-05-21 21:16:16: SocketManager: Starting
Thrown: FileException: Could not open file
LogManager::log: FileException: Could not open file
Thrown: FileException: Could not open file
LogManager::log2: FileException: Could not open file
^CLogging: 2017-05-21 21:16:20: core: Shutting down...
Thrown: FileException: Could not open file
LogManager::log: FileException: Could not open file
Thrown: FileException: Could not open file
LogManager::log2: FileException: Could not open file
Shut downBusy pool objects: 0

I've pasted the scripts files and config files as required (in the same way as in the windows build of adchpp, where it works fine)
I can paste the entire compile log if needed
(it seems to compile fine, with
# collect2 0.68 0.06
Move("build/debug-default/bin/socket/core.so", "build/debug-default/lua/LuaSocket/socket/core.so")
scons: done building targets.
at the end)
^This is from my rpi arm build, I've also tried x64 debug build and x64 release build options with the same apparent success in compilation.

I also tried manually doing chmod 777 to all files in the build folder and running as sudo, still the same issues, seems to not be compiling properly.

[eMTee (realprogger)]

Make sure you read the install and set up hub part in http://adchpp.sourceforge.net/user_guide/basic_guide.html (this doc is also included in the repo in plain text format).

I think the only issue here is the program can't find/open the default config dir, therefore all config/log/script etc... read/write file operations fail, as it printed to the console.

[Vinay Dargar (vinaydargar)]

Yeah I had looked at that but the process of the hub starting seemed to be stuck on the very beginning so it seems I missed some changes needed in the scripts config later on (the parts that weren't loading after the 2.12.1 (r"[unknown]") Debug running,) .

It turns out that running the hub via ./adchppd doesn't find the config/ folder right next to it, I tried explicitly using the what-I-thought-was-optional -c /path/to/config/folder switch to give it the same config/ folder and it launches fine.

I think that part of the doc should be fixed/clarified if the issue I had happens in general as well - "./adchppd" alone doesn't work, it needs ./adchppd -c /path/to/config.

Thanks for your reply, I'll proceed setting up my hub, should be fine now.

[eMTee (realprogger)]

Well, 'In Linux, the default location for configuration files is "/etc/adchpp/".' This is from the doc above. That's why I linked it. I'm not sure how to clarify this more.
Anyway, glad you were able to make it work.

[Vinay Dargar (vinaydargar)]

Ah, my bad. Not sure how I missed that line, I thought I had gone through the doc well enough.
Thanks though.

[Vinay Dargar (vinaydargar)]

Hi, I have another question but maybe a new post would be too much for it - I'm having trouble registering a user/first admin to the new hub I have set up. I seem to have made all the needed files and changes and there are no error messages in the software log, but when connected to the hub doing +regme test or +test or even +help has no response at all. I tried copying the user.txt from the hub files on the Windows distribution I mentioned before, I had registered as per the First_Reg.cmd, with a oplevel of 10. Using that file in the linux-running hub has the client stuck after sending the password.

In case of not yet registered and no response in hub to +help etc after connection:
AWAB entering IDENTIFY
AWAB entering NORMAL
TI56 entering IDENTIFY
TI56 entering NORMAL
WI4Q connected
WI4Q ready
WI4Q entering IDENTIFY
WI4Q verifying IP 0.0.0.0
WI4Q verifying CID R3ZRC4U7H2LU3WASRXRJYY2PRHB7XDV6V3YFWQY
WI4Q verifying nick TheLastGuardian
WI4Q entering NORMAL

When I use a users.txt file containing a registration for my nick, it has
entering VERIFY
at the end, stuck beyond that.
I have checked settings.txt, min level to chat is 0, allowreg is 1, and so on. (same settings as the windows build, in which all works as expected.

Any ideas where the issue might be?

[eMTee (realprogger)]

If +help has no response at all then the scripts are not loaded and running. I suggest again to search for the word 'Linux' in the doc and learn the differences of the setup compared to Windows. There aren't many, and mostly path related.

Copying the user.txt or any other from the hub files on the Windows distribution could work just make sure you convert the file to the Unix text format (CRLF at the line endings can cause problems under Linux).

[Vinay Dargar (vinaydargar)]

Hi, thanks for your response. I've looked through the doc and made all the changes I could see.
I rechecked the line endings of all the files in the config and scripts directory, all are unix LF.

Actually, I had waited for a few minutes before concluding that there was "no response" to +help and "stuck at logging in after sending password", but after a while I decided to wait a while longer. I noticed that the response would come almost exactly 15 minutes after the input, not that it never comes.
To clarify,
--> login with a unregistered nick -> immediate connection -> type +regme test or +help or anything -> about 15 minutes and a few seconds later -> expected response.
--> login with a registered nick -> waits at "stored password sent" for 15 minutes + a second or two, then proceeds as expected. type anything after that, it takes either a few seconds, or exactly 15 minutes, for a response.

For example, when I connected with an registered nick (and tried another nick with the same client):
[05-22-17 13:13:08] *** Connecting to adc://10.3.11.111:2781 ...
[05-22-17 13:13:08] *** Connected
[05-22-17 13:28:09] <TITAN> This hub is running ADCH++ 2.12.1 (r"[unknown]") Debug
[05-22-17 13:28:09] <TITAN> Registration data updated (new nick)
[05-22-17 13:28:09] <TITAN> Welcome back
[05-22-17 13:28:09] <TITAN> Displaying the last 0 messages
[05-22-17 13:28:09] <TITAN> Hub description content goes here
[05-22-17 13:28:09] <TITAN> MOTD content goes here
[05-22-17 13:28:09] <TITAN> Rules content goes here
[05-22-17 13:48:33] <dwqsada> .
[05-22-17 13:48:33] <dwqsada> .

There is a 15 minute delay after entering the password and the hub connecting. The network between them is fine throughout however.

The dc client is airdc++ 3.40 on windows 10, the host is a raspberry pi 2b, both are on the same lan (connected to the same router by lan cable), have tested about 40-60mbits of network throughput between them, ping <2ms as expected, no load on the rpi and nothing else past a few percent of cpu load running on it.

From what I've read in the doc I've made the needed linux changes, and the hub does work apart from the 15minute lag. I can regnick and +test and so forth with a 15 minute delay, and I also get the history of mainchat from the history.lua script (immediately when logging in with an unregistered user)

For reference, debug log:
pi@artypi:~/titanadc/bin $ ./adchppd -c /home/pi/titanadc/bin/config
Starting.
Core initialized
.Processing HubName
Processing Description
Processing Log
Processing LogFile
Processing MaxCommandSize
Processing BufferSize
Processing MaxBufferSize
Processing OverflowTimeout
Processing DisconnectTimeout
Processing LogTimeout
.
2.12.1 (r"[unknown]") Debug running, press ctrl-c to exit...
Logging: 2017-05-22 15:07:44: ScriptManager: Starting
Logging: 2017-05-22 15:07:44: PluginManager: Script.so loaded
Logging: 2017-05-22 15:07:44: BloomManager: Starting
Logging: 2017-05-22 15:07:44: PluginManager: Bloom.so loaded
Logging: 2017-05-22 15:07:44: SocketManager: Starting
Logging: 2017-05-22 15:07:44: SocketManager: Listening on 0.0.0.0:2780 (Encrypted: Yes)
Logging: 2017-05-22 15:07:44: SocketManager: Listening on [::]:2780 (Encrypte...

[Vinay Dargar (vinaydargar)]

Update: I tested it on my laptop (linux, x64 ubuntu 16.04), everything (scripts, login, +help/test, etc) works fine without any delay. It's only on the raspi with the same hub settings that causes a 15 minute delay. Anything I should look at to figure out the cause?

[eMTee (realprogger)]

No idea. Maybe try to install a ncdc client to the rasp and see if the issue manifests when logging in from localhost?

[Vinay Dargar (vinaydargar)]

Just tried that, ncdc on the raspi on localhost works fine with the adchpp hosted on the pi. ncdc on the linux laptop connecting to the rasp also works fine. Tried DC++ on the laptop connecting to the pi, also works fine. Looks like a AirDC++ issue, trying to narrow it down and figure it out, since I've been using it for a couple of years with no troubles.

Thanks for your help and guidance, I appreciate it!