I’ve come to suspect there is some kind of shutdown bug at the interface with the operating system on openjdk and shutdownhooks
To be clear i’m not talking about problems from the jdk (there is a hilarious one where if you try to serialize a File that came from a JFileChooser in a shutdownhook it will throw a exception because JFileChooser ‘files’ are a fake flyweight object that depends on a shutdown hook of the jdk to not leak memory)
I’m talking about the jvm exiting - naturally, by escaping the main or run of all threads - before the buffers are committed to disk - a outputstream.flush() is NOT the same as a disk sync.
When i tried to get the file descriptor of the corresponding fileoutputstream and force the issue with the sync method during shutdown, sometimes i would get a SyncFailedException.
I only really suspect this because actually getting information after a certain point in the shutdown turns impossible - all ‘unflushed’ ‘unsynced’ log files start to go nowhere - found this by repeated experimentation and comparing the point where the log stopped making sense - it just disappeared sometimes late in the shutdown
I suspect the shutdown init.d or upstart or systemd or whatever protocol is turning off the discs before the application shutdown hooks flush the data, therefore missing the final ‘sync’.
I also suspect the one sure fire way to prevent this (i already optimized what i have to write to disk by performing amortized writes) is to have a init.d|somethingelse script before umount preventing the normal shutdown sequence from going on if it detects the process still in operation and force a sync in the application at the written files in the shutdownhook.
I’m unhappy with this turn of events and i’d like to rant to whoever designed init.d
And oh, i’d like systemd to do better if it can