The windows service will stop itself after host sleeped/hibernated

[aflyhorse]

Might be a minor problem. I'll look into it.

[aflyhorse]

@gsliepen Excuse me, how did you create the current windows release nowaday?
I was trying to fix this problem, but I could not create a "service friendly" windows binary.

Most of my problem is that the binary always want to look for /usr/local/etc/tinc/tinc.conf. I've tried mingw64 in cygwin, and mingw64 on debian as your demo said.
The pure cygwin build said Could not open Windows tap device {xxxxx} (xxx) for reading: (31) A device attached to the system is not functioning. Tap reader failed!. I've not investigated it yet.

[gsliepen]

On Mon, Oct 17, 2016 at 01:06:53AM -0700, Chen Chen wrote:

@gsliepen Excuse me, how did you create the current windows release nowaday?
I was trying to fix this problem, but I could not create a "service friendly" windows binary.

Most of my problem is that the binary always want to look for /usr/local/etc/tinc/tinc.conf. I've tried mingw64 in cygwin, and mingw64 on debian as your demo said.
The pure cygwin build said Could not open Windows tap device {xxxxx} (xxx) for reading: (31) A device attached to the system is not functioning. Tap reader failed!. I've not investigated it yet.

The binary is created exactly as mentioned in the cross-compiling
example. However, the Windows installer sets a registry key that tells
tincd.exe where to look for its configuration files. If this registry
key is not set, tinc falls back to the default paths that it is compiled
with. If you didn't specify any, autoconf will tell tinc to use
/usr/local/etc/.

The registry key is \\HKEY_LOCAL_MACHINE\Software\tinc.

If you don't want to use a registry key, but want tincd.exe to use
better directory, run configure with the following option:

--sysconfdir='C:/Program\ files/tinc' --localstatedir='C:/Program\ files/tinc'

Don't worry about the forward slashes; Windows handles those just fine.
If you really want backslashes, replace each / with \\\\.

Met vriendelijke groet / with kind regards,
Guus Sliepen [email protected]

[aflyhorse]

Status update: still playing around Windows Service Hooks, with no significant progress.
PBT_APMSUSPEND might be some hint.

[aflyhorse]

After further investigation, the new 1.1 branch is not affected by this problem.
Since the network of two branches is somewhat compatible, I'm happy to close this issue and marked it as resolved.

[aflyhorse]

And much appreciate for the kindly help from gsliepen! Thank you!