Extending the startup services

[markNZed]

Should the docker image use systemd ? The advantage of this would be making it easy to follow guides for Ubuntu on the web.

Another option would be to have a directory where the user can put scripts that get called when the container starts. This would make it easier to extend.

It might be wiser to build on top of a light system like runit e.g. https://github.com/dockerimages/ubuntu-runit/blob/master/Dockerfile

[accetto]

No, my images do not use systemd. The reason is, that it's not really suitable for Docker containers at the moment. My images resemble virtual machines - and it's by intention - but in reality are Docker containers pretty different from virtual machines.

Otherwise is your reasoning correct and I would also welcome support of systemd. Maybe it'll come from the Docker itself, because they've acquired Nestybox. It's called Sysbox now and they claim to support systemd, besides other things. However, according my testing it's not really matured yet.

You can also check this docker systemctl replacement project, for example.

[accetto]

Another option would be to have a directory where the user can put scripts that get called when the container starts. This would make it easier to extend.

This option is actually already available.

You can, for example, put you scripts into bound folders and start them from .bashrc.

Another possibility is to design some helper scripts, like I do with my Firefox plus features.

You could also extend the startup script itself or provide your script as a parameter by container start. Check the Startup options and help part of any full README.

Another kind of customization is Overriding VNC/noVNC parameters.

However, be aware that designing a working image is not so easy as it seems. A good example is our discussion #39 about binding the whole $HOME directory. If you do it, the container will only seemingly initialize correctly. You can recognize it by the missing Version Sticker icon on the desktop. However, by the images without GUI desktops you can usually bind the whole $HOME directory without big problems.

Actually the correct and better way of extending the images is via Dockerfiles. Extension scripts would be more suitable for particular use cases or groups of use cases.

[markNZed]

Why not use docker-systemctl-replacement ?

Thanks for pointing out the command option support, this seems like the easiest option.

I am extending with a Dockerfile but this still leaves the original entrypoint. I want to run a VPN at startup and I was looking for where to put that.

[accetto]

I've considered docker systemctl replacement some years ago, but I've decided against it. I'm using tini, which is probably not a bad decision, because it has been adapted by the Docker itself since then.

Btw, I'm not sure if you've noticed that systemctl is available in my containers:

which systemctl
/usr/bin/systemctl

You can override the entry pont in your Dockerfile or compose file or even docker run statement. However, you have to care about the correct container initialization.

You have several options:

• You can extend or completely re-write my start-up scripts
• You can start you stuff in .bashrc
• You can use cron or similar to execute a script that will start your stuff
• You can start your stuff as a service, if it's possible
• You can start your stuff manually inside the container

[markNZed]

Another option is to have startup scripts associated with the desktop XFCE in ~/.config/autostart that is discussed at https://unix.stackexchange.com/questions/669372/xfce4-session-and-startup-where-are-autostart-items-saved