We have a simple dockerfile, similar to:
FROM resin/armv7hf-debian
ENV INITSYSTEM on
CMD /app/start.sh
However, this does not cause systemd to start as expected.
Exposing this device to the environment variable INITSYSTEM on via Resin.io does however make it start.
Why is this and what’s the difference?
Hi @niklasnorin
I just pushed the dockerfile you posted and got this in the logs, it looks like systemd is enabled to me. Do you not see the same logs or expect a different output?
15.08.17 17:04:17 (+0100) Systemd init system enabled.
15.08.17 17:04:18 (+0100) systemd 215 running in system mode. (+PAM +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP -APPARMOR)
Hey @niklasnorin, did you ever get to the bottom of this?
I’ve actually not had time to look into it since we found a workaround. I’ll update this thread when I’ve had the time to take a look again.
Thanks for checking in 
Great, let us know if you find anything interesting
Hi
The reason for this issue is that we are building the container using “resin build --emulated” in our own jenkins setup, and there it seems then that the INITSYSTEM is not added as env. I.e like:
We’re still seeing this issue (we have resolved it temporarily by setting INITSYSTEM via the resin dashboard), and are interested in figuring out how to resolve it in our build system.
Any hints (we’re runing resin cli 6.13.3)?
We believe this issue to be fixed in v6.13.4 of resin-cli. Would you mind giving it a try and letting us know here if it’s still a problem.
Note that INITSYSTEM is now gone: https://www.balena.io/docs/reference/base-images/base-images/#major-changes
I’ve ever since tried using without success.
My containers keeps exiting right away example https://travis-ci.com/mstormi/openhabian/builds/120994710
Quite something isn’t right here.
EDIT: I found this thread and it works (somewhat) if I use the entry.sh from the base image
Please correct the example code!
The docs still link to this entry.sh which still makes use of the INITSYSTEM variable.
Your example Dockerfile uses code (STOPSIGNAL, VOLUME) I don’t understand so I don’t know if it’s mandatory and what it is good for.
Hello there,
Thanks for posting! To start with the Dockerfile:
VOLUME signifies that an external volume will be mounted into the service container. In balenaOS, this is usually a named volume specified in the docker-compose.yml. See https://docs.docker.com/storage/volumes/ for more detailsSTOPSIGNAL signifies the signal that is sent to the process that started the service container upon container termination. In our case, it is 37 which is ‘resource lost’. This allows our system to correctly determine what’s occurred and choose the specified policy for what it should do on a service exit. See https://docs.docker.com/engine/reference/builder/#stopsignal for more detailsFinally, I shall contact the maintainer of the example to see if this is the correct behaviour. I think it may be, assuming that the INITSYSTEM variable is going to be defined by the user as to whether systemd should be used or not, but I’ll leave that to him to respond if this is not the case.
Best regards, Heds
Thanks for the pointers on VOLUME and STOPSIGNAL.
But please remove them from the examples as they’re not mandatory and that’s somewhat irritating. Or complement them with extensive comments to explain what you just did here.
Well at least that would be in conflict with your docs (link in last post). They say INITSYSTEM is deprecated. So either of these should be corrected, and I think it’s the example.
When you contact the example maintainer please also ask what CMD has to look like. I might have misunderstood this but the container terminates when it’s done with CMD. An initsystem replacement on the other hand should be a demon like systemd to run forever, shouldn’t it ?
I ended up issuing a CMD ‘sleep xxx’ so I can connect to the container (docker exec …) while that’s running but clearly that’s a hack, can you please provide a more clever example setup ?
Finally, my main issue and reason for playing around with the initsystem is still unresolved. Whenever I use systemctl, I get error messages like those below. I read it’s a big hassle but is there a way to have systemd run as PID 1 ?
I think the most useful example would be the code one needs to deploy to get the initsystem working just the way it did before you introduced that breaking change.
Guess that’s most others would be interested, too.
systemctl status xyz
System has not been booted with systemd as init system (PID 1). Can't operate.
Hi Markus,
We have an example with systemd here https://github.com/balena-io-library/base-images/tree/master/examples/INITSYSTEM/systemd/systemd.v230
You’ll need to add a CMD line at the end of the Dockerfile (something like CMD sleep infinity) and ENV INITSYSTEM on in the beginning.
That I know already, see my last-but-one post: this example makes use of the INITSYSTEM variable which is in contrast to your docs saying that INITSYSTEM is no longer available.
did that already, see my previous post
Meanwhile I use start.sh from the OS repo which essentially does the same (endless noop loop).
But my problem remains, on every systemctl use I get
System has not been booted with systemd as init system (PID 1). Can't operate.
I started replacing systemctl … with service … but I’d like to stick with systemctl.
So how do I start systemd as PID 1 ?
Hi @mstormi,
I actually wrote a self-contained systemd example a little while back (although it was actually to demonstrate advertising MDNS services). It’s here: https://github.com/balena-io-playground/avahi-zoo-publisher
If you look at the avahi-publisher directory, you’ll see that the Dockerfile.template uses one of our Debian Stretch base images (including NodeJS) and then installs systemd, masks services which don’t/shouldn’t run in Docker, and then sets the STOPSIGNAL (and this is required, as it’s the prescribed way to correctly shut down systemd, see here: https://www.freedesktop.org/software/systemd/man/systemd.html#SIGRTMIN+3 ) and then details the standard entry point to use (the script here: https://github.com/balena-io-playground/avahi-zoo-publisher/blob/master/avahi-publisher/entry.sh , which documents what it’s doing). This then allows any CMD to be used for the actual service running (or no CMD at all, if you don’t want it to do anything else).
Another point to note is that if you’re not running a privileged (or single service) container, you will need to ensure that container groups are correctly mounted using tmpfs within the container, and that is has enough security permissions to do this. You can look at the docker-compose file here: https://github.com/balena-io-playground/avahi-zoo-publisher/blob/master/docker-compose.yml to see what’s required.
Hopefully this will help you get up and running with as little issues as possible. Meanwhile, we still have the outstanding question on our documentation raised internally, which we will discuss.
Best regards, Heds
Thanks for your answer and example. I meanwhile got things to work but I admit I had some lack of understanding that I cannot force systemd to be PID #1
It is somewhat logical if you run multiple containers, "there can be only one 
" but I think it still should be possible if I did run a single container only. Still like to hear if someone has a solution to enforce that.
The real problem though actually is not with systemd or the environment to enforce a different PID but with the systemctl command (to complain systemd does not run as #1).
FTR, my solution was to get a systemctl replacement from here. It does not insist on systemd to have PID 1.
Hi, that sounds good! Glad you got it working. We’ll take a look at what you posted, see if we can add it to our own documentation as well, so it could help others too!
Hi @mstormi,
I think it’s worth noting here that my example does exactly that, running systemd as PID 1 in the service container. If you take a look at it, you’ll be able to carry out exactly what you want.
Best regards, Heds