# Changelog v1.16.1

**URL:** <https://forum.storj.io/t/changelog-v1-16-1/10042>\
**Category:** STORJLINGS\
**Tags:** official-changelog\
**Created:** [November 3, 2020, 6:38pm UTC](https://forum.storj.io/t/changelog-v1-16-1/10042 "2020-11-03T18:38:18Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![littleskunk](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/littleskunk/32/63_2.png) [@littleskunk](https://forum.storj.io/u/littleskunk)\
**Post date:** [November 3, 2020, 6:38pm UTC](https://forum.storj.io/t/changelog-v1-16-1/10042/1 "2020-11-03T18:38:18Z")

</div>

> **[Release v1.16.1 · storj/storj](https://github.com/storj/storj/releases/tag/v1.16.1)**
>
> Changelog
> General
> 
> \[+ c641540\] docs/blueprints: graceful exit initial refactoring (#3938)
> 
> Storagenode
> 
> \[+ 9df7433\] storagenode: secret db and service added
> \[+ 89bdb20\] storagenodedb/orders: select...

**For Storage Nodes**

**Linux Auto Updates**  
We finished the Linux storage node updater and would love to get some help testing it. We are looking for storage node operators with the skill to manually create a service. Later down the road, we are going to publish a Linux installer and we also want to add the Linux updater to our docker container. So don’t worry if you can’t create a service file. This only means we will come back to you in one of the following test rounds. More information you can find here: [[Tech Preview] Linux Storage Node & Updater](https://forum.storj.io/t/tech-preview-linux-storage-node-updater/10041)

**Downtime Tracking Enabled**  
We still had a feature flag from the old days and the audit service didn’t report back offline nodes. This is now fixed. We expect to see a good uptime score on the storage node dashboard.

---

<div class="post-metadata">

**Author:** ![joesmoe](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/joesmoe/32/63_2.png) [@joesmoe](https://forum.storj.io/u/joesmoe)\
**Post date:** [November 3, 2020, 6:43pm UTC](https://forum.storj.io/t/changelog-v1-16-1/10042/2 "2020-11-03T18:43:36Z")

</div>

Really cranking out the updates quickly these days!

---

<div class="post-metadata">

**Author:** ![Storgeez](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/storgeez/32/68_2.png) [@Storgeez](https://forum.storj.io/u/Storgeez)\
**Post date:** [November 4, 2020, 12:29am UTC](https://forum.storj.io/t/changelog-v1-16-1/10042/3 "2020-11-04T00:29:48Z")

</div>

For the past 2 years or so!

---

<div class="post-metadata">

**Author:** ![TOR](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/tor/32/1125_2.png) [@TOR](https://forum.storj.io/u/TOR)\
**Post date:** [November 4, 2020, 7:46am UTC](https://forum.storj.io/t/changelog-v1-16-1/10042/4 "2020-11-04T07:46:55Z")

</div>

How many hours of downtime are allowed then?

---

<div class="post-metadata">

**Author:** ![baker](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/baker/32/6110_2.png) [@baker](https://forum.storj.io/u/baker)\
**Post date:** [November 4, 2020, 2:33pm UTC](https://forum.storj.io/t/changelog-v1-16-1/10042/5 "2020-11-04T14:33:47Z")

</div>

> [@littleskunk](#):
>
> **Downtime Tracking Enabled**  
> We still had a feature flag from the old days and the audit service didn’t report back offline nodes. This is now fixed. We expect to see a good uptime score on the storage node dashboard.

I believe this means that downtime tracking has been enabled, but DQ for downtime has not. The current plan once DQ for downtime is enabled is to start with up to 288 hours of downtime before disqualification (although this is a simplification since there are other factors at play). The hours of allowed downtime is expected to be reduced as the system is optimized. See this post for more info:

> [@Changelog v1.12.3](https://forum.storj.io/t/changelog-v1-12-3/9049/24):
>
> One update on the downtime tracking topic: If you managed to collect too much downtime you will get suspended first. The satellite gives you 7 days to fix the issue and additional 30 days later the satellite will make a decsision. So lets say we are strict and would suspend for 48 hours downtime and you managed to be offline for 2 days in a row. You get your storage node back online but these 48 hours of downtime will not go away for the next 30 days. You would be suspended for 30 days. Luckily…

---

<div class="post-metadata">

**Author:** ![HeroHann](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/herohann/32/62_2.png) [@HeroHann](https://forum.storj.io/u/HeroHann)\
**Post date:** [November 10, 2020, 4:07pm UTC](https://forum.storj.io/t/changelog-v1-16-1/10042/6 "2020-11-10T16:07:36Z")

</div>

Should everyone update or is running 1.15.3 fine to run for the next weeks?  
I update manually so that’s no point for me…

---

<div class="post-metadata">

**Author:** ![dragonhogan](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/dragonhogan/32/6078_2.png) [@dragonhogan](https://forum.storj.io/u/dragonhogan)\
**Post date:** [November 10, 2020, 7:33pm UTC](https://forum.storj.io/t/changelog-v1-16-1/10042/7 "2020-11-10T19:33:22Z")

</div>

Couple of questions:

1. Mostly out of curiosity, what’s the purpose of this new “secret.db” ?
2. Downtime tracking, or as it’s displayed on dashboard “online” in percentage, is this just a running value, or is this based on a set period of time (i.e. per month and resets at the start of every month) or a rolling period of time (last 30 days)?
3. Linux Auto Updates: this is an initiative to move the update functionality out of “watchtower” container and into the “storagenode” container (i.e. 2 containers down to 1?) I assume the idea is that it would help control the linux update roll out timing and prevent folks from not updating?
