I've been trying to make a taskd server work on my computer (Arch Linux) for days. The problem I'm facing now is that taskd's config documentation (https://taskwarrior.org/docs/taskserver/troubleshooting-sync.html) says that I have to use the output of hostname -f as an address (I do not know what 'CN' abbreviates). I've also tried with my local IP address starting with 192.168 but that gave me the handshake error you can find in the troubleshooting guide I linked.

I started investigating a little, because I couldn't access my taskserver from other machines. I found this:

When I listen to the port I use, let it be 54000, using nc -l -p 54000, I can see this as the output of ss -lntu | grep 54000:

tcp    LISTEN   0        10      *

Whereas when I start taskd, which listens on the same port, ss gives me:

tcp    LISTEN   0        4     *

Now from a different machine, I tried checking the port while listening with nc -vv 192.168.x.y 54000 (with the server's IP address) and I found that when the local address is, the port shows as open. Otherwise it shows up as closed. I think this is because is essentially localhost and I can't see that from my network?

taskd also has a config file with a server option where I entered the output of hostname -f, which is watermelon.localdomain, as I was instructed by the documentation. I suppose that's what's translated to localhost, right?

I would greatly appreciate your help, thanks in advance!

UPDATE 2018/04/21

I managed to solve the problem by setting the server variable in the config to, this way I got taskd to listen for any address on port 54000. Now everything works beautifully. The documentation of taskd was a bit vague on the topic I guess.

  • 2
    CN is an abbreviation for Common Name (usually a fully qualified domain name). So if hostname -f returns watermelon.localdomain, the instructions are saying to use e.g. CN=watermelon.localdomain. According to the taskd website, CN=localhost is the default value and thus is not valid. Regarding vs., is a local loopback address and typically indicates the port is only available to processes on the same machine. In contrast, in this case effectively means "all IPv4 addresses on the local machine" (incl. any IP that is network-accessible). Apr 17, 2018 at 22:36
  • 1
    Concerning the configuration files, my understanding is that the entry should be something like e.g. taskd.server=watermelon.localdomain:54000 (but I could be wrong). Apr 17, 2018 at 22:36
  • @Anaksunaman I think you're right... But why does the server listen on the loopback address then? I don't get it.
    – bp99
    Apr 18, 2018 at 14:42
  • 1
    My assumption would be that is likely the first (or only) IPv4 address available to watermelon.localdomain (assuming you are using that in your configuration). The taskd website does indicate you can potentially use e.g. your_network_ip:54000 (vs. e.g watermelon.localdomain:54000) - taskwarrior.org/docs/taskserver/protocol.html Apr 19, 2018 at 21:49
  • @Anaksunaman I managed to solve the problem --- I was really dumb it seems (see updated question). Thanks for your help!
    – bp99
    Apr 21, 2018 at 10:29

1 Answer 1


Sockets are configured to listen on a specific IP and Port. There are typically two primary configurations you would use for a Socket and a third that isn't as common, but comes in handy.

1) To only allow communication from the machine running the service

This is configured when you see ONLY the host machine can access this service. You can use something like a reverse proxy to allow access externally, but nothing on the network will be allowed to connect to it.

2) To all machines on any network reachable from the server

This is configured when you see This allows anything to talk to this service as long as the packets can get to it.

3) To only a specific network the server is joined to

This is configured when you see (or whatever IP). This means that ONLY this subnet of this network is allowed access.

If you want to allow your service to be connected from other machines on the network, it needs to be bound on or the local IP.

  • Thanks for your detailed answer! Do you have any idea how I should make taskd listen on then?
    – bp99
    Apr 18, 2018 at 14:41
  • it's likely in the config for taskd. Look for some kind of entry indicating 'bind port' or 'bind address'. It might be listed as already. But the best thing is to check the docs for taskd
    – Andrew
    Apr 18, 2018 at 15:24
  • I found this relevant question just now: stackoverflow.com/questions/44902884/… The answerer mentions 'ensuring /etc/hosts was set with the externally facing IP addresses'. Could you please explain what that means and whether that is a good idea? It seems to have worked for the OP of that question.
    – bp99
    Apr 18, 2018 at 16:15
  • 1
    /etc/hosts has no impact on the service's ability for other hosts to connect. It does allow the local machine to properly reference iteslf, but there should be no reason to change it as long as the hostname still matches the systems' configured hostname.
    – Andrew
    Apr 18, 2018 at 20:59
  • I managed to solve the problem since (see updated question). You helped a lot though, thanks.
    – bp99
    Apr 21, 2018 at 10:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .