Journal issues with supervised install after updating to 2022.11

I updated HA to this version, and facing the following issue:

Unsupported system - Network Manager issues
System is unsupported because Network Manager is missing, inactive or misconfigured.

my NetworkManager is up and recent, version 1.30.6

NetworkManager.service         loaded active running Network Manager
1 Like

With HA update, I also made Supervisor update.
HA is running on Pi OS with Supervisor 1.3.1

I reinstalled OS/Supervisor, made an PI updates, and all seems to be working again.

This is exactly what I’m encountering as well.

1 Like

Yep, 30 second fix including the Google search to figure out how to do it since in the betas the information was not displaying properly.

1 Like
● systemd-journal-remote.service - Journal Remote Sink Service
     Loaded: loaded (/lib/systemd/system/systemd-journal-remote.service; indirect; vendor preset: disabled)
     Active: failed (Result: exit-code) since Sun 2022-11-06 14:58:19 MSK; 3h 0min ago
TriggeredBy: ● systemd-journal-remote.socket
       Docs: man:systemd-journal-remote(8)
             man:journal-remote.conf(5)
   Main PID: 18946 (code=exited, status=1/FAILURE)

Nov 06 14:58:19 homeassistant systemd[1]: Started Journal Remote Sink Service.
Nov 06 14:58:19 homeassistant systemd-journal-remote[18946]: Failed to read key from file '/etc/ssl/private/journal-remote.pem': Permission denied
Nov 06 14:58:19 homeassistant systemd[1]: systemd-journal-remote.service: Main process exited, code=exited, status=1/FAILURE
Nov 06 14:58:19 homeassistant systemd[1]: systemd-journal-remote.service: Failed with result 'exit-code'.

still got this error :frowning: any suggestinons welcome )

I’m running Supervised HA on a System where is installed Openmediavault 6.
I had the journal issue as well as NetwokManager issue and also the CGroup version issue.
I did exactly:
apt-get install systemd-journal-remote -y
wget https://github.com/home-assistant/supervised-installer/releases/latest/download/homeassistant-supervised.deb
dpkg -i homeassistant-supervised.deb

I rebooted and everithing seems to be ok.
The logs are working and no issues reported.
thank you!

4 Likes

Following these steps does indeed make the installation supported and healthy again. However the journal issues remain.
As a peculiarity i get spammed with these logs after accessing “host logs”:

Nov 07 11:49:16 systemd-journal-gatewayd[328373]: microhttpd: Setting TCP_NODELAY option to ON state failed: Operation not supported
Nov 07 11:49:16 systemd-journal-gatewayd[328373]: microhttpd: Setting TCP_CORK option to OFF state failed: Operation not supported
Nov 07 11:49:16 systemd-journal-gatewayd[328373]: microhttpd: Failed to push the data from buffers to the network. Client may experience some delay (usually in range 200ms - 5 sec).
3 Likes

Yup, this caught me too. After installing the correct deb and rebooting, the warning message went away. Thanks! Who knows how long it would have taken me to spot that issue…

Thanks! this solved the issue on my Raspberry 3 too…

This solved the issue for me too thanks. Debian Bullseye

But if you check your HOST log, you will se that something spamming it, as Caligo wrote. For me too.

Thank you!
This helped me!
systemd-journal-gatewayd service started, НА unsupport message disappeared!

Yes it’s started, but spammed log with these:

● systemd-journal-gatewayd.service - Journal Gateway Service
     Loaded: loaded (/lib/systemd/system/systemd-journal-gatewayd.service; indirect; vendor preset: disabled)
     Active: active (running) since Fri 2022-11-11 09:14:32 CET; 5min ago
TriggeredBy: ● systemd-journal-gatewayd.socket
       Docs: man:systemd-journal-gatewayd(8)
   Main PID: 8249 (systemd-journal)
      Tasks: 2 (limit: 4915)
     CGroup: /system.slice/systemd-journal-gatewayd.service
             └─8249 /lib/systemd/systemd-journal-gatewayd

Nov 11 09:19:26 raspberrypi systemd-journal-gatewayd[8249]: microhttpd: Failed to push the data from buffers to the network. Client may experience some delay (usually in r>
Nov 11 09:19:26 raspberrypi systemd-journal-gatewayd[8249]: microhttpd: Setting TCP_NODELAY option to ON state failed: Operation not supported
Nov 11 09:19:26 raspberrypi systemd-journal-gatewayd[8249]: microhttpd: Setting TCP_CORK option to OFF state failed: Operation not supported
Nov 11 09:19:26 raspberrypi systemd-journal-gatewayd[8249]: microhttpd: Failed to push the data from buffers to the network. Client may experience some delay (usually in r>
Nov 11 09:19:26 raspberrypi systemd-journal-gatewayd[8249]: microhttpd: Setting TCP_NODELAY option to ON state failed: Operation not supported

This worked perfectly for my installation thank you

On HAOS in a VMware VM I get this…
It seems to function though.
It also has docker cgroup v2, which doesn’t get flagged as unhealthy/unsupported

systemctl status systemd-journal-gatewayd.socket


● systemd-journal-gatewayd.socket - Journal Gateway Service Socket
     Loaded: loaded (/lib/systemd/system/systemd-journal-gatewayd.socket; enabled; vendor preset: disabled)
     Active: active (running) since Fri 2022-11-11 16:58:26 AEDT; 10h ago
   Triggers: ● systemd-journal-gatewayd.service
       Docs: man:systemd-journal-gatewayd(8)
     Listen: /run/systemd-journal-gatewayd.sock (Stream)
      Tasks: 0 (limit: 9255)
     Memory: 0B
     CGroup: /system.slice/systemd-journal-gatewayd.socket

Nov 11 16:58:26 dock64 systemd[1]: Listening on Journal Gateway Service Socket.



systemctl status systemd-journal-gatewayd.service

● systemd-journal-gatewayd.service - Journal Gateway Service
     Loaded: loaded (/usr/lib/systemd/system/systemd-journal-gatewayd.service; indirect; vendor preset: disabled)
     Active: active (running) since Fri 2022-11-11 13:58:51 UTC; 1h 12min ago
TriggeredBy: ● systemd-journal-gatewayd.socket
       Docs: man:systemd-journal-gatewayd(8)
   Main PID: 4784 (systemd-journal)
      Tasks: 2 (limit: 2350)
     Memory: 233.4M
        CPU: 1.761s
     CGroup: /system.slice/systemd-journal-gatewayd.service
             └─ 4784 /usr/lib/systemd/systemd-journal-gatewayd

Nov 11 13:58:51 haosVM systemd[1]: Started Journal Gateway Service.
Nov 11 13:58:51 haosVM systemd-journal-gatewayd[4784]: microhttpd: MHD_OPTION_EXTERNAL_LOGGER is not the first option specified for the daemon. Some messages may be printed by the standard MHD logger.
#



systemctl status systemd-journal-gatewayd.service

○ systemd-journal-gatewayd.service - Journal Gateway Service
     Loaded: loaded (/usr/lib/systemd/system/systemd-journal-gatewayd.service; indirect; vendor preset: disabled)
     Active: inactive (dead)
TriggeredBy: ● systemd-journal-gatewayd.socket
       Docs: man:systemd-journal-gatewayd(8)




systemctl start systemd-journal-remote
systemctl status systemd-journal-remote

× systemd-journal-remote.service - Journal Remote Sink Service
     Loaded: loaded (/usr/lib/systemd/system/systemd-journal-remote.service; indirect; vendor preset: disabled)
     Active: failed (Result: exit-code) since Fri 2022-11-11 14:05:30 UTC; 3s ago
TriggeredBy: ● systemd-journal-remote.socket
       Docs: man:systemd-journal-remote(8)
             man:journal-remote.conf(5)
    Process: 4951 ExecStart=/usr/lib/systemd/systemd-journal-remote --listen-https=-3 --output=/var/log/journal/remote/ (code=exited, status=1/FAILURE)
   Main PID: 4951 (code=exited, status=1/FAILURE)
      Error: 2 (No such file or directory)
        CPU: 199ms

Nov 11 14:05:30 haosVM systemd[1]: Started Journal Remote Sink Service.
Nov 11 14:05:30 haosVM systemd-journal-remote[4951]: Failed to read key from file '/etc/ssl/private/journal-remote.pem': No such file or directory
Nov 11 14:05:30 haosVM systemd[1]: systemd-journal-remote.service: Main process exited, code=exited, status=1/FAILURE
Nov 11 14:05:30 haosVM systemd[1]: systemd-journal-remote.service: Failed with result 'exit-code'.


pi 3b barebones install haos
I don’t have physical access to it atm to check further

I don’t have a barebones pi4 setup atm either.

Nov 11 16:35:33 homeassistant systemd-journal-gatewayd[13067]: microhttpd: MHD_OPTION_EXTERNAL_LOGGER is not the first option specified for the daemon. Some messages may be printed by the standard MHD logger.


pi4 deb/docker/supervisor
healthy and supported

Capture

sudo systemctl status systemd-journal-gatewayd.service
● systemd-journal-gatewayd.service - Journal Gateway Service
     Loaded: loaded (/lib/systemd/system/systemd-journal-gatewayd.service; indirect; vendor preset: disabled)
     Active: active (running) since Fri 2022-11-11 17:04:37 AEDT; 10h ago
TriggeredBy: ● systemd-journal-gatewayd.socket
       Docs: man:systemd-journal-gatewayd(8)
   Main PID: 9117 (systemd-journal)
      Tasks: 2 (limit: 9255)
     Memory: 582.9M
     CGroup: /system.slice/systemd-journal-gatewayd.service
             └─9117 /lib/systemd/systemd-journal-gatewayd

Nov 12 02:19:04 dock64 systemd-journal-gatewayd[9117]: microhttpd: Failed to push the data from buffers to the network. Client ma>
Nov 12 02:19:04 dock64 systemd-journal-gatewayd[9117]: microhttpd: Setting TCP_NODELAY option to ON state failed: Operation not s>
Nov 12 02:19:04 dock64 systemd-journal-gatewayd[9117]: microhttpd: Setting TCP_CORK option to OFF state failed: Operation not sup>
Nov 12 02:19:04 dock64 systemd-journal-gatewayd[9117]: microhttpd: Failed to push the data from buffers to the network. Client ma>
Nov 12 02:19:04 dock64 systemd-journal-gatewayd[9117]: microhttpd: Setting TCP_NODELAY option to ON state failed: Operation not s>
Nov 12 02:19:04 dock64 systemd-journal-gatewayd[9117]: microhttpd: Setting TCP_CORK option to OFF state failed: Operation not sup>
Nov 12 02:19:04 dock64 systemd-journal-gatewayd[9117]: microhttpd: Failed to push the data from buffers to the network. Client ma>
Nov 12 02:19:04 dock64 systemd-journal-gatewayd[9117]: microhttpd: Setting TCP_NODELAY option to ON state failed: Operation not s>
Nov 12 02:19:04 dock64 systemd-journal-gatewayd[9117]: microhttpd: Setting TCP_CORK option to OFF state failed: Operation not sup>
Nov 12 02:19:04 dock64 systemd-journal-gatewayd[9117]: microhttpd: Failed to push the data from buffers to the network. Client ma>
...skipping...

sudo systemctl status systemd-journal-gatewayd.socket
● systemd-journal-gatewayd.socket - Journal Gateway Service Socket
     Loaded: loaded (/lib/systemd/system/systemd-journal-gatewayd.socket; enabled; vendor preset: disabled)
     Active: active (running) since Fri 2022-11-11 16:58:26 AEDT; 10h ago
   Triggers: ● systemd-journal-gatewayd.service
       Docs: man:systemd-journal-gatewayd(8)
     Listen: /run/systemd-journal-gatewayd.sock (Stream)
      Tasks: 0 (limit: 9255)
     Memory: 0B
     CGroup: /system.slice/systemd-journal-gatewayd.socket

Nov 11 16:58:26 dock64 systemd[1]: Listening on Journal Gateway Service Socket.

sudo systemctl status systemd-journal-remote
● systemd-journal-remote.service - Journal Remote Sink Service
     Loaded: loaded (/lib/systemd/system/systemd-journal-remote.service; indirect; vendor preset: disabled)
     Active: inactive (dead)
TriggeredBy: ● systemd-journal-remote.socket
       Docs: man:systemd-journal-remote(8)
             man:journal-remote.conf(5)



Also for what its worth I couldn’t remove the

ha jobs options --ignore-conditions healthy

from one of my VMs (the only I had actually used that on)

ha job reset
ha jobs reset
ha supervisor restart 

Wouldn’t clear the flag.

ha supervisor repair 

Also didn’t clear it.
Even after a host reboot it was still getting flagged as unsupported due to the ignored flag.

Just like Caligo mentioned.

Everything is working correctly in HA but if you look at the host logs you will see all the systemd-journal-gatewayd errors.

It would be nice to see if anyone knows how to resolve these log error.

I have followed multiple solutions here (like re-installing and such) and nothing has worked to clear the logs.

2 Likes

I’m curious why you’re running supervised in a vm when you can simply run HassOS and avoid all these issues?

There’s plenty of posts that discuss fixing this. Just read some of the previous posts. It’s 3 or 4 lines of commands.

Don’t think I listed supervised in a VM…

The VM I listed is HAOS.
VMware on win10

The pi3 is HAOS.

The pi4 is barebones supervised.
The pi4 was a fresh install Yesterday.

Although I do have some supervised VMs setup…
It was mostly for testing Bluetooth on my addon, so those are not really recent installs.

Your host operating system in a VM would be listed as HassOS not Debian if you were running HassOS. The images you share show Debian. :man_shrugging:

Unless that’s unrelated.