Umbrel 1.1 installation tracking

Hello

Context: Installation on a Raspberry Pi 4 (RPI4) with an SSD running Umbrel OS 1.1 (released a month ago).
The integration is under review here, but I wanted to test on a real RPI (not in a VM).

I recently restored a Gladys Plus backup on a brand new Umbrel installation (to test the behavior on this OS).

I get the following error at the end of the restore and had to start the gladys container manually (everything has been working fine since).

2024-04-23T15:14:36+0200 \u003cinfo\u003e gateway.restoreBackup.js:39 (Gateway.restoreBackup) Backup restored. Need reboot now.
2024-04-23T15:14:36+0200 \u003cinfo\u003e system.shutdown.js:13 (System.shutdown) Database is probably already closed
2024-04-23T15:14:36+0200 \u003cwarn\u003e system.shutdown.js:14 (System.shutdown) Error: SQLITE_MISUSE: Database is closed
    at /src/server/node_modules/sequelize/src/dialects/sqlite/connection-manager.js:31:79
    at node:internal/util:441:7
    at new Promise (\u003canonymous\u003e)
    at node:internal/util:427:12
    at /src/server/node_modules/sequelize/src/dialects/sqlite/connection-manager.js:31:85
    at Array.map (\u003canonymous\u003e)
    at ConnectionManager._onProcessExit (/src/server/node_modules/sequelize/src/dialects/sqlite/connection-manager.js:31:10)
    at ConnectionManager.close (/src/server/node_modules/sequelize/src/dialects/abstract/connection-manager.js:116:23)
    at Sequelize.close (/src/server/node_modules/sequelize/src/sequelize.js:1292:35)
    at System.shutdown (/src/server/lib/system/system.shutdown.js:11:26)
    at Gateway.restoreBackupEvent (/src/server/lib/gateway/gateway.restoreBackupEvent.js:18:23)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at EventEmitter.\u003canonymous\u003e (/src/server/utils/functionsWrapper.js:13:7) {
  errno: 21,
  code: 'SQLITE_MISUSE'
}

Ah, it might be due to the option in the docker-compose

restart: on-failure

So I have a strange behavior. The Gladys container cannot contact localhost (which is a problem for contacting MQTT).

The ping localhost returns ping: bad address 'localhost'

The ping 127.0.0.1 works.

I’ve checked everything (/etc/hosts, DNS, loopback interface, container in network mode: host). I’m stumped

Hi @cicoub13 :slight_smile:

Indeed, the restore mechanism relies on Gladys being automatically restarted if it « self-kills ». If you’re on restart: on-failure, it no longer works. You need to be on restart: always!

[quote=« cicoub13, post:3, topic:8853 »]
So I’m seeing

A message has been split into a new topic: Docker : restart=always vs unless-stopped dans le cas de Gladys?

I had managed to get everything working and made the PR here Add gladys assistant by cicoub13 · Pull Request #1044 · getumbrel/umbrel-apps · GitHub

But they’re asking lots of questions about our fairly extensive access. I’ll reply trying to explain why we need them (like Home Assistant…).

Cool, great @cicoub13 :slight_smile:

I saw the questions; indeed, it’s quite surprising that they’re asking those questions given that they give the same permissions to Home Assistant: umbrel-apps/home-assistant/docker-compose.yml at master · getumbrel/umbrel-apps · GitHub

Let me know if you need help answering

nmfretz (Nathan Fretz) · GitHub seems to have more expertise and understands a large part of the parameters.

I commented, adding details about our need.

I’m a bit stuck on the cgroup: host and privileged: true. Could you tell me the reason for these parameters?

1 Like

Thanks @cicoub13 for the answers, I’ve added my answers for cgroup and privileged

A negative response regarding exposing the Docker daemon (too risky). They propose several solutions here Add gladys assistant by cicoub13 · Pull Request #1044 · getumbrel/umbrel-apps · GitHub

Docker-in-Docker seems interesting to me (even for us), but it seems complex and I wonder about the usefulness for Gladys outside Umb

Hello @cicoub13 !

I saw the reply — needs testing, but for me Docker in Docker doesn’t work and it’s actually very shaky.

Running a Zigbee2mqtt container inside another container, will it have access to the system (Privileged? USB port?)

From what I understand, the Umbrel project wants to retain control of the host and not allow containers to launch other containers, whereas that’s exactly what we’re trying to do ^^

If their project doesn’t accept this behavior, rather than implementing hacks, it’s probably better not to allow this behavior in those installations and the user can simply use Z2M in remote mode, same for MQTT…

But it should be tested!

I wonder if these applications (Portainer, Home Assistant) are really used within Umbrel?

Hi @cicoub13 :slight_smile: I’m checking in on this topic!

In light of their last reply, I gave up. I think the dev/time investment isn’t worth it today.

What I don’t understand is why it’s a yes for HA and not for us. Well, they’re trying to do better, and so we’re a bit late :neutral_face:

What if we just drop the « container launch » part? Since we can now connect to an existing Zigbee2mqtt container, that’s fine :slight_smile:

Given that Gladys detects when the Docker daemon isn’t available, there should normally be no change to the product?

It’s just a single line to change on the Umbrel PR

1 Like