Hi all,
For a project, we would like to specify some docker run flags with which the balena containers are started. Is it possible to do this in any way? More specifically, we would like to set the -d flag to run the container as daemon.
Thanks in advance!
Tim Resink
RRC Robotics
Hey @tresink
What is your reason for wanting to do this? The -d flag in docker run is shorthand for detached, which just means that the CLI will print the container ID and then return.
Hi @CameronDiver,
We want to use systemctl inside the container. We are using containers as a light VM and really need this functionality. We tried the solution recommended by https://www.balena.io/docs/reference/base-images/base-images/#installing-your-own-initsystem but this did not work for us. As an alternative I am using this project that replaces systemctl by functionality that does not need systemd --> https://github.com/gdraheim/docker-systemctl-replacement. However, I found somewhere that you need to run containers with the -d flag in order for it to work.
Oh and the mesage we keep getting is the infamous ‘System has not been booted with systemd as init system (PID 1). Can’t operate.’
Cheers!
Tim
Hi Tim,
As Cameron mentioned, the -d flag makes sense in the CLI context only - it’s what allows to detach your terminal from the started container.
If you push a release to a device with balena system, container is managed by supervisor, and you don’t use the CLI unless you develop in local mode and ssh to the device to do some experiments, starting containers manually.
Have you tried running our examples (without modifications) with systemd linked in the docs?
Are you getting the same error?
Hi @roman-mazur,
Okay, that is clear. But it could still be desirable to be able to set the docker run flags sometimes such as network settings, I imagine. Or can you set such properties in the docker-compose.yml?
I have incorporated your dockerfile in our own dockerfiles, using your resin.service file and the entry.sh without modification, without any luck.
@tresink
Yes, it’s possible to configure a lot of things with docker-compose file.
Specifically, in your case, it’s important to run this container with init system in the privileged mode.
So setting
privileged: true
on your service is something you may need to do.
If it still does not work, would you please attach the init system container logs you get after pushing a release?
Hi @roman-mazur,
I tried to use it out of the box, but I cant seem to start the container with your entry.sh directly. The container exits immediately after startup. Am I missing something haha?
Hi @tresink it might be worth pushing this https://github.com/balena-io-playground/balenalib-systemd-example which is a multicontainer example with systemd installed. Once you validate that this is working as expected, then work backwards and port the changes to your project 
Yes this works, thanks!
Now that I have used it some more, I notice that whenever I reboot a device, the systemd errors show up again! Do you have any suggestions why?
Which systemd errors @tresink ?
Are you using https://github.com/balena-io-playground/balenalib-systemd-example ?
Can you please share the code you are deploying?
Here is a screenshot of what is happening. I am using a slightly adapted version of the https://github.com/balena-io-playground/balenalib-systemd-example . I put the adjusted code and the output of journalctl in the container in files on this link.
Is it possible for you to share the custom code that you applied for us to better understand what’s going on?
Oh sorry, didn’t see the link. Nevermind! Checking the code now
@tresink I see that the changes you made to the project are mainly to add udev support, is that correct? I think there’s something wrong in the entry.sh then, most likely.
We have some pending PR for this, that might work for you:
Could you get the code from that PR (which is this udev branch), and add your base image changes (and leave the entry.sh as it is for the time being) and see if that works for you? In our testing it worked.
You also should not add
network_mode: host
devices:
- '/dev:/dev'
most likely, as the first doesn’t play well with udev as much as I know, and the second should be unnecessary.
Would love to hear when you had a chance to try!
Hey, based on our testing, the udev modifications were no merged, and can try the master branch, if you want:
Looking forward whether this fixes things for you!
Hi @imrehg,
Unfortunately, this did not change anything for us! I tried the adapted entry.sh and removed the network_mode: host. Although I don’t understand why this would not play well with udev. We need both the network privileges as well as the udev eventually.
Cheers,
Tim
Hey @tresink rereading the issues, sorry that we weren’t totally clear that it’s the bluetooth that is not healthy. We are trying to reproduce things here closer to yours.
Can you give a bit more information:
entry.sh and docker-compose.yml changes you mentioned?We are gathering hardware here to be able to reproduce, and in my initial attempts I run into different issues with bluetooth in that container than you did, hence the question of trying to solve the same issue.
Thanks!