Hassio supervisor not starting

Found a couple of threads re: the same problem I am experiencing but have been unable to solve. Running HA in docker on Raspbian Lite on a rpi4. Rebooted the system this morning and supervisor isn’t coming back up.

Below is what I am seeing in the docker logs for hassio-supervisor. Image info:
io.hass.version=214

20-04-04 19:38:23 INFO (MainThread) [supervisor.discovery] Load 1 messages

Traceback (most recent call last):

  File "/usr/local/lib/python3.7/runpy.py", line 193, in _run_module_as_main

    "__main__", mod_spec)

  File "/usr/local/lib/python3.7/runpy.py", line 85, in _run_code

    exec(code, run_globals)

  File "/usr/src/supervisor/supervisor/__main__.py", line 47, in <module>

    loop.run_until_complete(coresys.core.setup())

  File "uvloop/loop.pyx", line 1456, in uvloop.loop.Loop.run_until_complete

  File "/usr/src/supervisor/supervisor/core.py", line 79, in setup

    await self.sys_ingress.load()

  File "/usr/src/supervisor/supervisor/ingress.py", line 56, in load

    self._cleanup_sessions()

  File "/usr/src/supervisor/supervisor/ingress.py", line 74, in _cleanup_sessions

    valid_dt = utc_from_timestamp(valid)

  File "/usr/src/supervisor/supervisor/utils/dt.py", line 87, in utc_from_timestamp

    return UTC.localize(datetime.utcfromtimestamp(timestamp))

OverflowError: timestamp out of range for platform time_t

Sd card could be dieing a slow death

Not running on sd card. Moved to SSD running on raspbian lite two weeks ago

Problem is documented happening with supervisor 207 on Ubuntu but can’t find any reference of it occurring elsewhere:

Did you ever get to the bottom of this? I seem to have exactly the same issue after restarting.

Never did. I ended up using a backup and completely re-installing. After spending two full days trying to troubleshoot it was easier and took me 2 hrs tops to get everything back up and running.

Anyone have any ideas? I just went from 17 to 19 and it’s back



20-04-23 03:32:57 INFO (MainThread) [supervisor.discovery] Load 1 messages

Traceback (most recent call last):

  File "/usr/local/lib/python3.7/runpy.py", line 193, in _run_module_as_main

    "__main__", mod_spec)

  File "/usr/local/lib/python3.7/runpy.py", line 85, in _run_code

    exec(code, run_globals)

  File "/usr/src/supervisor/supervisor/__main__.py", line 47, in <module>

    loop.run_until_complete(coresys.core.setup())

  File "uvloop/loop.pyx", line 1456, in uvloop.loop.Loop.run_until_complete

  File "/usr/src/supervisor/supervisor/core.py", line 77, in setup

    await self.sys_ingress.load()

  File "/usr/src/supervisor/supervisor/ingress.py", line 56, in load

    self._cleanup_sessions()

  File "/usr/src/supervisor/supervisor/ingress.py", line 74, in _cleanup_sessions

    valid_dt = utc_from_timestamp(valid)

  File "/usr/src/supervisor/supervisor/utils/dt.py", line 87, in utc_from_timestamp

    return UTC.localize(datetime.utcfromtimestamp(timestamp))

OverflowError: timestamp out of range for platform time_t

Got exactly the same issue. Spend some time to investigate, but found the exact reason of the issue.
Sometimes, for whatever reason, it is possible that incorrect session data may appear in /usr/share/hassio/ingress.json. As far as I understand, session data is being stored in this file.

ingress.py doesn’t validate data from this json file, and passes timestamp to utility function, where bad timestamp causes error.

Solution is to remove all or most sessions from /usr/share/hassio/ingress.json file.

I’m going to propose fix, validating sessions data in ingress.py to avoid future issues with this.