@spacekitteh, thanks for your PR! By analyzing the history of the files in this pull request, we identified @ehmry, @joachifm and @edolstra to be potential reviewers.

Why is the bindsTo needed?

Because it requires networking to be up before it can create a connection. If you have a slow-starting network connection, then cjdns will fail if it's started too soon after starting networking.

If networking goes down, then having cjdns running is pointless; I'm also not sure if it can even re-establish a connection after losing the network yet.

It's also a security thing - if networking goes down and cjdns doesn't properly reauthenticate peers when it's re-established, an attacker could perform a MITM.

networking.target gives no guarantee that networking is up. You might want to depend on network-online.target

systemctl list-dependencies sleep.target --reverse --type=target --all 
sleep.target
● ├─systemd-hibernate.service
● │ └─hibernate.target
● ├─systemd-hybrid-sleep.service
● │ └─hybrid-sleep.target
● └─systemd-suspend.service
●   └─suspend.target

Depending on sleep.target should suffice, since the other three will pull in sleep.target

networking.target gives no guarantee that networking is up. You might want to depend on network-online.target

Yeah, I changed it to that. It still seems to have issues. Apparently network-online.target comes up before the connection is properly established (for my hardware), so the service tries rebooting (too quickly) and hits the start up rate limit. But due to having a "Restart=" option set, combined with rate limiting being different from the default, it doesn't attempt any further restarts.

Then the same thing happens with the cjdns-resume.service. I can't figure this out - I don't understand why rate limiting combined with restart means don't restart after being rate limited!

I guess I could just disable start rate limiting. I'll give that a try.

Well, it works now. \o/ I squashed the commits.

@groxxda what do you think of the current state?

I don't use cjdns so I cannot say anything about the issues @spacekitteh experienced.
At least the upstream service file does not require network-online, and I don't understand why this is needed here.

I don't know why ordering after network-online does not work, that may be a bug in the networking module. Of course I'd favor fixing the real issue and not working around it in clients with unlimited restarts, but that's just my opinion.
If it was broken before and works like this, it's clearly an improvement..

Is it good to merge?

Note my comment about systemd unit descriptions.

@edolstra Where?

I don't think an attacker can perform an MITM: cjdns does end-to-end authentication based on addresses.

@cjdelisle is it possible to implement a signal handler for SIGUSR2 to reconnect to its peers? That would make the cjdns-restart.service cleaner IMHO.

Merged in 016fa06, thank you for your effort and time on this :)

\o/