Maarten's questions

More and more applications have manuals telling you to preferrably run it within a docker container. But if you want an application to follow the system runlevels of the linux operating system that your docker container is running on and be controllable with commands like 'sudo service myservice start' and 'systemctl enable myservice' then it is much easier to make it a systemd service. Running it without docker can be cumbersome. I could narrow this question to Java Spring Boot Applications because that's my main use case for the applications I write myself, but I would rather come to a more generic approach to do this in a way that it is:

• easy to configure
• survives reboots gracefully
• keeps most or all the advantages of systemd control

Ofcourse there will be reasons why I should not want this approach and I can guess some of the responses that will follow. I am interested in that. Things should be as simple as possible, but not simpler (Einstein something). But describing a simple approach that will work could benefit the Linux and Docker community.

In response to some earlier answers below (thanks for the valuable feedback!): I prefer to control all individual applications on my operating system by one means of control. By default that would be systemd because that's the default of the operating system for that. I know using a container is a bit of a different paradigm then running it on the OS itself, but I don't really know what rule I would be breaking if I would create a systemd service like 'homeassistant-container', that controls starting and stopping a docker container with (in this case) 'homeassistant' as an application within that container

My Lenovo P50 laptop used to suspend nicely when I closed the lid on Ubuntu 19.10. After the upgrade this doesn't work anymore. When I execute the command sudo systemctl suspend then the laptop still goes into a very rapid full functional suspend. So something seems to go wrong somewhere in handling the lid close event from acpi.

I'm using gnome-tweak-tools and it has the toggle to suspend on lid close enabled as expected.

I also checked the configuration in /etc/systemd/logind.conf and it seems perfect:

HandleLidSwitch=suspend
HandleLidSwitchExternalPower=suspend
HandleLidSwitchDocked=suspend
LidSwitchIgnoreInhibited=yes

I haven't found anything noticable in the /var/log/syslog.

The workaround I found is the following:

Create a file called /etc/acpi/events/laptop-lid-close with the following content:

event=button/lid LID close
action=/etc/acpi/laptop-lid-close.sh

And create a file /etc/acpi/laptop-lid-close.sh with the following content and gave it execute rights (chmod +x /etc/acpi/laptop-lid-close.sh):

#!/bin/sh

systemctl suspend

Would be better if this workaround would not be necessary ofcourse

Acpi seems to fire off 'lid close' events as it should, otherwise the workaround would not work. Also the suspend itself must be working on my laptop as well for the same reason.

Any clues on how to learn why this doesn't work out of the box?

After upgrade from 17.10 to 18.04, any device I connect to only stays connected for a couple of seconds. My laptop is a Lenovo P50 (20ENCTO1WW)

/var/log/syslog reports:

pulseaudio[????]: [pulseaudio] bluez5-util.c: Information about device /org/bluez/hci0/dev_???????? invalid
bluetoothd[????]: Endpoint replied with an error: org.bluez.Error.InvalidArguments

Obviously the question marks represent some id's (pid's and bluetooth id in this case)

Any clue on fix or workaround?