What version of Windows are you running? I was able to install Cache for Windows (x86-64) 2017.1 (Build 726U) Thu Dec 8 2016 22:41:57 EST on Windows 7 (Ensemble installation). It was an upgrade from a previous version. It would be worth looking at the Windows event log to see if there were errors in there. If you don't get an answer here quickly, I suggest opening up a WRC issue.
You aren't actually writing a response. To get the result in the terminal, you'd need to 'write' the output instead of 'do'.
This means that the SuperServer spawned a child job to handle incoming connections (this is what happens when any incoming connection comes to the SuperServer). After this child job starts up, it tried to read the connection information from the client, but the message wasn't there. This could be caused either by a slow network or by something that's simply attempting to connect to the SuperServer but not actually making a real connection (possibly testing that port). I would take a look at that IP address (10.251.10.16) to see what that is. My best guess is it's some sort of monitoring software if all 4 servers report the same IP address in their errors.
You need the %All role to run this, per the following documentation: http://docs.intersystems.com/latest/csp/documatic/%25CSP.Documatic.cls?…
Note that this was reported to Wireshark a few months ago, and they said they would update their installer such that it avoids this Microsoft bug. I haven't updated Wireshark recently, but I believe they've already implemented this for their latest versions.
This should be scripted to be done as part of the cluster failover process, much in the same way you previously had it configured to be scripted on system startup.
At this point, I suggest opening a WRC issue.
It's likely that you didn't actually export the SQL Privileges. You can do that via ^SECURITY -> System parameter setup -> Export All Security settings. This will allow you to specifically export just SQL Privileges records if you answer 'no' to 'Export ALL security records?'
If all you're really looking to do is shut down the instance, you can do this with a $zf(-2) callout to the OS to call 'ccontrol stop <instance> quietly restart' (or 'ccontrol stopstart <instance>' if you are on Windows). Do not use $zf(-1) for this, as shutdown would wait for the $zf(-1) calling process until reaching the ShutdownTimeout value. See this doc for an example of using $zf(-2):
http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY…
Caché should always be shut down separately before the OS is shut down, and that would completely avoid this issue, allowing Caché to go through its normal shutdown procedure.
Mirrored databases also need to be journaled, so if you are running a mirrored environment, consider whether you need the data to exist (and be consistent) after a failover or not. If not, you could make that particular database non-mirrored and disable journaling for it.
Mirrored databases also need to be journaled, so if you are running a mirrored environment, consider whether you need the data to exist (and be consistent) after a failover or not. If not, you could make that particular database non-mirrored and disable journaling for it.
Are you actually making any changes to the data? If so, you should use a read-write reporting async. If not, it'd be useful to know the exact errors you're getting.
One important question when investigating these types of problems: is it one process, a couple processes, or many processes making the majority of these entries? You can find this out by viewing the file, either in the Management Portal or via JRNDUMP. More frequently than not, it's simply one runaway process, and it's quite either to either just terminate it, or at least determine what it's doing by inspecting the process itself.
You should not be using $zu calls directly, as these are internal and subject to change. As Alexander suggested, you should use $zf(-1) (or $zf(-2))
It sounds to me that something could be wrong with the parent process of the one you are trying to kill. If you haven't already, I strongly suggest opening a WRC issue for this. It would be worth trying to get a trace (ltrace or strace) of both this process and the parent to see what is going on at the OS level.