A bunch of questions.
I’ve casually noticed just when issuing a docker stop command that it takes like… up to 15 seconds? to stop storagenode running now.
It’s better to do it this way instead of KILL:
It’s a recommended timeout on case of locks or a very slow system, like rpi. But in your case you need to find the optimal timeout for your system under load.
When I send TERM it usually exits within 1 second. The concern is that if it actually needs more in some corner cases – my UPS can only sustan the sytem for 5 min..
So I take it sending KILL is not a good idea? Somethign gets corrupted? If so, how do I clean up on the next boot?
KILL may corrupt something, like SQLite databases, maybe it can also leave some not deleted partial uploaded pieces, but they would be cleaned with a garbage collector eventually. If you migrated to hashstore, it may not have a time to flush the received piece to the log file if your system under load.
If TERM works great, why do you need KILL?
I don’t. I send TERM, following KILL, if it did not shut down in 30 seconds. This is default behaviour for most services.
My question is hypothetical – whether there are any safeguards and what will I lose, but so far it shuts down every time gracefully within a second.
I actually never saw a KILL on my nodes, except the case when I attempted to migrate my server to Linux:
It was so slow with NTFS, that even 300 seconds not always was enough. 
Of course, if this server worked stable under Linux, it wouldn’t use NTFS.
Thats a like a Tarantino horror movie!. NTFS on linux, forced windows updates, and then node on linux on ntfs, because why not at this point 
NTFS on linux is a reverse engineered unstable crap, that does not support half the features. And NTFS itself is not suitable for anything serious. The ReFS was promising but like everything half-decenlt microsoft murdered. But that’s a rant for a differnt day.
Of course I knew about this. This exercise was specifically for users, who:
Yeah, you could just as well run networking on RFC 1149. And each Thursday morning after a full moon it would still be better than running a node on a Synology box.
We might need to go modern with RFC 2549 
.. wouldn’t want to keep the StorJ customers waiting too long on TTFB 
(sorry couldn’t resist this sitetrack hah..)
Anyway for my nodes I use a waittime of max 45 secs, and force shutdown afterwards - ie. in controlled shutdown script for my nut configuration if UPS runs dry.
Havnt seens issues - even with heavy load, shutdown is almost instant- so in my mind it’s more a matter of a safeguard in case something is really wrong with the host.
Of course. Why else would you inflict such pain on yourself.
I also like experimenting and proofs
Linux console SNO here, kill -SIGINT has always terminated the storagenode process right quick on my setup(s). To my understanding it is equivalent of tapping CTRL-C in the console. A far as I’ve been able to tell, storagenode process does handle CTRL-C cleanly.
kill -KILL, kill -SIGKILL or oldskool kill -9 all sound like an overkill to me.
Buy I like my Synology box 
BTRFS implementation on md raid is pretty alright, and when just used for ISCSI, there’s plenty of performance.
… shit
The only thing I don’t like with Synology NASes is the awful noise they make, but they work pretty well for Storj. I hope I don’t jinx them, but in 5 years, I didn’t had any hardware fail. I baught spare chargers and fans, but I didn’t had to use any so far.
Synology hardware is very good. Especially the metal units. It’s well thought out, with attention to details, and very serviceable.
It’s their software, marketing, company direction, and customer service that sucks. So pretty much – everything else around the hardware.
And if you look at it further critically – it’s not that hard to find a good hardware. And not vendor-locked at that, too. So, no, synology is shit. “it did not break for me yet” is not a good justification to stay with them. It’s a Stockholm syndrome speaking. Vote with your $$ and buy a server, install FreeBSD (none of that linux GPL nonsense) and improve your level of happiness (at least in the area of running services). That’ what I would have done. And I had. And I"m very happy. (Still on the path of getting rid of GPL from around my life, but that’s a story for a different topic)