I will definitely check this when I get back to the office tomorrow. I'll keep you posted.
Thanks and regards, Elias On 29 July 2014 21:13, Juergen Sauermann <juergen.sauerm...@t-online.de> wrote: > Hi, > > that makes me think that APserver is listening on a different socket type > than the one apl is using. > Therefore, netstat -l -p to see where APserver listens and apl -l 37 to > see where apl tries to connect. > > /// Jürgen > > > > > On 07/29/2014 03:07 PM, Elias Mårtenson wrote: > > I don't think so. The APserver is definitely started. Also, if I start > another apl it's able to connect to the previous one. > > My theory is the same as before, I think that apl attempts to connect to > APserver before it's ready to accept connections. > > Also, given the fact that apl never connects to APserver, it's not very > strange that it's not killed when apl exits. > > In the case where I start a second apl that connects to the first > APserver, it does get killed properly. > > Regards, > Elias > On 29 Jul 2014 21:02, "Juergen Sauermann" <juergen.sauerm...@t-online.de> > wrote: > >> Hi Elias, >> >> looks like either no APserver is running or the APserver listens on >> another socket. >> Check with netstat -l -p. That should show a line like: >> >> tcp 0 0 localhost:16366 *:* >> LISTEN 2631/APserver >> >> If the APserver does not get killed then this is the problem I had >> earlier but could not reproduce. >> If you can reproduce it, please uncomment the *#define USE_POLL* at the >> beginning of *APserver.cc* >> and reinstall. That will tell us if *poll()* works better than *select()*. >> If not, we could try tcp_keepalive to >> see if that works better. >> >> /// Jürgen >> >> On 07/29/2014 05:27 AM, Elias Mårtenson wrote: >> >> The following happens on my Arch Linux system. >> >> When I start the apl binary (without Emacs) I'm getting a "connection >> refused" error. The log with *-l 37* is reproduced below. >> >> The APserver is properly started (I can see it in the process listing), >> but after I call )OFF, it doesn't get killed. >> >> Note that if I start APserver separately, I do not get any errors, and >> everything seems to work correctly. >> >> Here's the output from -l 37 (errors highlighted in red): >> >> $ *dist/bin/apl -l 37 --silent* >> sizeof(Svar_record) is 328 >> sizeof(Svar_partner) is 28 >> >> initializing paths from argv[0] = dist/bin/apl >> initializing paths from $PWD = /home/emartenson/src/apl >> APL_bin_path is: ./dist/bin >> APL_bin_name is: apl >> Reading config file >> /home/emartenson/src/apl/dist/etc/gnu-apl.d/preferences ... >> config file /home/emartenson/.config/gnu-apl/preferences is not >> present/readable >> 0 input files: >> Using TCP socket towards APserver... >> connecting to 127.0.0.1 TCP port 16366 >> (this is expected to fail, unless APserver was started manually) >> forking new APserver listening on 127.0.0.1 TCP port 16366 >> connecting to 127.0.0.1 TCP port 16366 >> (this is supposed to succeed.) >> ::connect() to existing APserver failed: Connection refused >> PID is 24054 >> argc: 4 >> argv[0]: 'dist/bin/apl' >> argv[1]: '-l' >> argv[2]: '37' >> argv[3]: '--silent' >> uprefs.user_do_svars: 1 >> uprefs.system_do_svars: 1 >> uprefs.requested_id: 0 >> uprefs.requested_par: 0 >> Svar_DB not connected in Svar_DB::is_registered_id() >> id.proc: 1001 at ProcessorID.cc:77 >> Processor ID was completely initialized: 1001:0:0 >> system_do_svars is: 1 >> * ⎕SVQ⍳0* >> Svar_DB not connected in Svar_DB::get_offering_processors() >> 100 210 >> >> Regards. >> Elias >> >> >> >
