Disque server fails with Connection Refused

[KidFashion]

I've a problem with disque server (which uses the same redis codebase so i think it's related to #365).

I've compiled it from sources and it raised no errors (or warnings), disque server starts without any complaint (not even with verbose logging) and it correctly takes port 7711 (because i can't start other listening socket on that port as long as the server is active) but each try to connect (using disque client or embedded unit tests) fails with "Connection refused" message.

Disque has no package so i cannot simply apt-get it and run as a service as suggested in #365 resolution.

Server startup below:

...>./disque-server
87:C 09 Oct 10:08:55.371 # WARNING: No config file specified, using the default config. In order to specify a config file use disque-server /path/to/disque.conf
87:P 09 Oct 10:08:55.371 # You requested maxclients of 10000 requiring at least 10032 max file descriptors.
87:P 09 Oct 10:08:55.371 # Server can't set maximum open files to 10032 because of OS error: Invalid argument.
87:P 09 Oct 10:08:55.371 # Current maximum open files is 2048. maxclients has been reduced to 2016 to compensate for low ulimit. If you need higher maxclients increase 'ulimit -n'.
87:P 09 Oct 10:08:55.389 * No cluster configuration found, I'm 5a474e6eb34da71093f4f89876d2b8e84b7dc3c0
                                        Disque 1.0-rc1 (0192ba7e/0) 64 bit
          _ -
        .                               Port: 7711
        .    o    .                     PID: 87
                 .
               -                              http://disque.io


87:P 09 Oct 10:08:55.409 # Server started, Disque version 1.0-rc1
87:P 09 Oct 10:08:55.409 * The server is now ready to accept connections on port 7711

Client failing connection below:

...> ./disque
Could not connect to Disque at 127.0.0.1:7711: Connection refused
not connected> exit

I don't know if useful but this is the content of my /proc/version:

Linux version 3.4.0-Microsoft (Microsoft@Microsoft.com) (gcc version 4.7 (GCC) ) #1 SMP PREEMPT Wed Dec 31 14:42:53 PST 2014

Thank you for your help,
Angelo

[rodrymbo]

I suppose for completeness you could also say what netstat -an on the Windows side tells you about something listening on that port (namely your disque-server), as well as whether you've tried setting Windows firewall to allow connections to the port? (I say completeness, because neither should be significant if you are just accessing something on localhost, your tests show other things can't bind to the port since it is in use, and neither clue is likely to reveal an answer to the problem.) Also, you can get a copyable Windows version string (e.g. Microsoft Windows [Version 10.0.14936]) by starting cmd.exe, since that reveals the version of the underlying WSL system. I'm not sure /proc/version reveals that much information, though it would be nice if it did.

The solution in #365 was to run it as a service. The sudo service redis-server start command is probably equivalent to sudo /etc/init.d/redis-server start where redis-server is a bash script located in /etc/init.d, put there by the package installer. If you have a copy of such a script you can probably cobble together your own for disque-server (those scripts are mostly very similar). There's more to the System V init / upstart, but since that isn't currently working, all you really need is a simple script (or even just a command line) to run it, foreground or background. It sounds like you already know what the basic part of that script/command needs to be.

You didn't say anything about using sudo. That was part of the solution in #365. Maybe that would get it going for you? It's not clear to me why that should be the case, but it might be worth a try.

[egocheer]

have same problem with @KidFashion . i can start the nginx and mysql server, there is not any error log, but when client connect the server, it response Connection refused. i try close the firewall and antivirus, still not work. when netstat -an on the Windows side , cound't see the 80 or 3306 port.

[KidFashion]

Yes, I was trying on localhost so I didn't added that port on windows firewall but for completion I disabled the firewall and tried again with the same result.
netstat -an shows the port in use but no further useful information i'm afraid:

...
  TCP    [::]:7680              [::]:0                 LISTENING
  TCP    [::]:7711              [::]:0                 LISTENING
  TCP    [::]:17711             [::]:0                 LISTENING
...

My window version string, according to cmd is Microsoft Windows [Versione 10.0.14393]

I didn't wrote it but I already tried launching it with and without sudo but unfortunately it made no difference.

Being not an expert in Linux I already tried to make it a service following quick & dirty suggestions at this page; with that script in place the command sudo service redis-server start worked and launched disque-server but with the same issue.

I didn't mention that because I was not sure it was the proper way to make it a service, I could try again adapting the redis script instead of writing a different one but I'm afraid it will make no difference.

[royale011]

Have the same problem, but it happens on my company project. I've tried to use WSL to do debug and test. Obviously, I cannot add my project process to service because I need its output, but however, there is one way to run redis not as service.

While running redis not as service, using netstat -an you could see something like that:
TCP [::]:6379 [::]:0 LISTENING
This is the redis host and port. If you check /etc/redis/redis.conf, find something like bind=127.0.0.1, that is supposed to be IP address binding redis. However the real IP address is [::], which is an IPv6 address that is equal to IPv4 address 0.0.0.0.

Then I've changed bind=127.0.0.1 to bind=0.0.0.0, run redis-server, change the config info of our project that setting redis host as [::], it turns out that our server process connect to redis normally, though redis-client will direct itself to 127.0.0.1 and then fail to connect, which should fix as running redis as a service.

However if I change our server to [::] (not 0.0.0.0) and start server and robots, the connection could establish:

TCP [::1]:10011 [::1]:19564 ESTABLISHED TCP [::1]:10011 [::1]:19565 ESTABLISHED TCP [::1]:10011 [::1]:19566 ESTABLISHED TCP [::1]:10011 [::1]:19567 ESTABLISHED TCP [::1]:10011 [::1]:19568 ESTABLISHED TCP [::1]:10011 [::1]:19569 ESTABLISHED TCP [::1]:10011 [::1]:19570 ESTABLISHED TCP [::1]:10011 [::1]:19571 ESTABLISHED TCP [::1]:10011 [::1]:19572 ESTABLISHED TCP [::1]:10011 [::1]:19573 ESTABLISHED TCP [::1]:10011 [::1]:19574 ESTABLISHED TCP [::1]:10011 [::1]:19575 ESTABLISHED TCP [::1]:10011 [::1]:19576 ESTABLISHED TCP [::1]:10011 [::1]:19577 ESTABLISHED TCP [::1]:10011 [::1]:19578 ESTABLISHED TCP [::1]:10011 [::1]:19579 ESTABLISHED TCP [::1]:10011 [::1]:19580 ESTABLISHED TCP [::1]:10011 [::1]:19581 ESTABLISHED TCP [::1]:10011 [::1]:19582 ESTABLISHED TCP [::1]:10011 [::1]:19583 ESTABLISHED TCP [::1]:10011 [::1]:19584 ESTABLISHED TCP [::1]:10011 [::1]:19585 ESTABLISHED TCP [::1]:10011 [::1]:19586 ESTABLISHED TCP [::1]:10011 [::1]:19587 ESTABLISHED TCP [::1]:10011 [::1]:19588 ESTABLISHED TCP [::1]:10011 [::1]:19589 ESTABLISHED TCP [::1]:10011 [::1]:19590 ESTABLISHED TCP [::1]:10011 [::1]:19591 ESTABLISHED TCP [::1]:10011 [::1]:19592 ESTABLISHED TCP [::1]:10011 [::1]:19593 ESTABLISHED TCP [::1]:19564 [::1]:10011 ESTABLISHED TCP [::1]:19565 [::1]:10011 ESTABLISHED TCP [::1]:19566 [::1]:10011 ESTABLISHED TCP [::1]:19567 [::1]:10011 ESTABLISHED TCP [::1]:19568 [::1]:10011 ESTABLISHED TCP [::1]:19569 [::1]:10011 ESTABLISHED TCP [::1]:19570 [::1]:10011 ESTABLISHED TCP [::1]:19571 [::1]:10011 ESTABLISHED TCP [::1]:19572 [::1]:10011 ESTABLISHED TCP [::1]:19573 [::1]:10011 ESTABLISHED TCP [::1]:19574 [::1]:10011 ESTABLISHED TCP [::1]:19575 [::1]:10011 ESTABLISHED TCP [::1]:19576 [::1]:10011 ESTABLISHED TCP [::1]:19577 [::1]:10011 ESTABLISHED TCP [::1]:19578 [::1]:10011 ESTABLISHED TCP [::1]:19579 [::1]:10011 ESTABLISHED TCP [::1]:19580 [::1]:10011 ESTABLISHED TCP [::1]:19581 [::1]:10011 ESTABLISHED TCP [::1]:19582 [::1]:10011 ESTABLISHED TCP [::1]:19583 [::1]:10011 ESTABLISHED TCP [::1]:19584 [::1]:10011 ESTABLISHED TCP [::1]:19585 [::1]:10011 ESTABLISHED TCP [::1]:19586 [::1]:10011 ESTABLISHED TCP [::1]:19587 [::1]:10011 ESTABLISHED TCP [::1]:19588 [::1]:10011 ESTABLISHED TCP [::1]:19589 [::1]:10011 ESTABLISHED TCP [::1]:19590 [::1]:10011 ESTABLISHED TCP [::1]:19591 [::1]:10011 ESTABLISHED TCP [::1]:19592 [::1]:10011 ESTABLISHED TCP [::1]:19593 [::1]:10011 ESTABLISHED

But the connection seems stucked. If I close server process at first, the robots process get a bunch of EOF error.

I don't know how redis could do this.Edit: It's our project's own bug. Fix it and the connection established normally.

[rodrymbo]

Just for laughs I installed the disque software. The server started okay:

15167:P 13 Oct 10:47:49.794 * The server is now ready to accept connections on port 7711

and the client seems to connect to it (leaving disque-server running in the other bash window):

:~ $ disque
127.0.0.1:7711> help
disque 1.0-rc1
Type: "help @<group>" to get a list of commands in <group>
      "help <command>" for help on <command>
      "help <tab>" to get a list of possible help topics
      "quit" to exit
127.0.0.1:7711>

This is with Microsoft Windows [Version 10.0.14942]. So maybe the problem has gone away for those in the Insider Preview? Also, I didn't tweak the firewall.

[KidFashion]

@rodrymbo This is interesting: since the redis issue (#365) is quite old could you try also redis and see if it also works on 10.0.14942?

[KidFashion]

After Creators update (or something similar...) now my BashOnWindows /proc/version became

Linux version 4.4.0-43-Microsoft (Microsoft@Microsoft.com) (gcc version 5.4.0 (GCC) ) #1-Microsoft Wed Dec 31 14:42:53 PST 2014

and the problem went away (disque is launching and allows client connection).

Closing the issue, thank you.