Docker and systemd - service stopping after 10 seconds - service

I'm having trouble getting a Docker container to stay up when it's started by systemd. When I start it manually with sudo docker start containername, it stays up without trouble, but when it's started via systemd with sudo systemctl start containername, it stays up for 10 seconds then mysteriously dies, leaving messages in syslog something like the following:
Mar 13 14:01:09 hostname docker[329]: time="2015-03-13T14:01:09Z" level="info" msg="POST /v1.17/containers/containername/stop?t=10"
Mar 13 14:01:09 hostname docker[329]: time="2015-03-13T14:01:09Z" level="info" msg="+job stop(containername)"
I am making the assumption that it's systemd killing the process, but I can't work out why it might be happening. The systemd unit file (/etc/systemd/system/containername.service) is pretty simple, as follows:
[Unit]
Description=MyContainer
After=docker.service
Requires=docker.service
[Service]
ExecStart=/usr/bin/docker start containername
ExecStop=/usr/bin/docker stop containername
[Install]
WantedBy=multi-user.target
Docker starts fine on boot, and it looks like it does even start the docker container, but no matter if on boot or manually, it then quits after exactly 10 seconds. Help gratefully received!

Solution: The start command seems to need the -a (attach) parameter as described in the documentation when used in a systemd script. I assume this is because it by default forks to the background, although the systemd expect daemon feature doesn't appear to fix the issue.
from the docker-start manpage:
-a, --attach=true|false
Attach container's STDOUT and STDERR and forward all signals to the process. The default is false.
The whole systemd script then becomes:
[Unit]
Description=MyContainer
After=docker.service
Requires=docker.service
[Service]
ExecStart=/usr/bin/docker start -a containername
ExecStop=/usr/bin/docker stop containername
[Install]
WantedBy=multi-user.target

Related

Creating a service to launch and restart a Python script

On a Virtual Maching running on Centos7, using root privileges, I want to create a service to launch a Python (Python 3.9) webservice and restart it every hour.
Here's what i did:
creating a directory /etc/systemd/system/dlweb_doc_webservice.service.d
creating a file dlweb_db_generate_report.service like this
[Unit]
Description=dlweb_db_generate_report_webservice
After=network-online.target
Wants=network-online.target systemd-networkd-wait-online.service
[Service]
Type = simple
ExecStart=/usr/local/bin/python3.9 /opt/scripts/dlweb_db_generate_report_webservice/dlweb_db_generate_report.py
Restart=on-failure
RestartSec=5s
StartLimitIntervalSec=3600
StartLimitBurst=5
[Install]
WantedBy=multi-user.target
running systemctl daemon-reload
running systemctl --type=service --all doesn't display my service
and
running systemctl enable dlweb_db_generate_report_webservice returned a Failed to execute operation: No such file or directory
What did i miss or do wrong?

Can't see my dbus object when program run from systemctl service

I have a cpp application which broadcasts an object and its methods on the dbus. I try to run this program at startup with the following service file:
[Unit]
Description=Running dbus program
After=network.target
[Service]
Type=simple
ExecStart=/home/my_name/Documents/dbus/build/my_app
StandardOutput=console+journal
StandardError=console+journal
[Install]
WantedBy=multi-user.target
After reloading:
systemctl daemon-reload
and running it:
sudo systemctl start my_service.service
I got no error in the journal, but I cant see anything on the dbus (running d-feet, and browsing for my object, I cant find anything)
Running the exact same ExecStart:
/home/my_name/Documents/dbus/build/my_app
in the console works fine.
What am I missing? Thanks!
As you want your service to run on the session bus you will need to use:
sudo systemctl --user start my_service.service
Putting the file into /etc/systemd/user/ location will make it available to all users still.

Is there a possibility to change restart policy of podman container?

Is there a possibility to change container restart policy using podman? We can set policy during creating container podman run --restart always, but how to change it when the container is created?
Using docker we have docker update command which allows us to do so. Unfortunately there is no podman update command. Can it be done? Or do I need to create a new container?
when using podman you should create a systemd service that will manage podman container.
create systemd file "/etc/systemd/system/containername.service"
[Unit]
Description=your container
[Service]
Restart=always
ExecStart=/usr/bin/podman start -a containername
ExecStop=/usr/bin/podman stop -t 2 containername
[Install]
WantedBy=local.target
run command:
systemctl daemon-reload
enable service to start at boot
systemctl enable containername.service
restart service
systemctl restart containername.service
You can also add some other restart systemd parameters like:
RestartSec (Configures the time to sleep before restarting a service), StartLimitInterval (seconds service is it not permitted to start any more), StartLimitBurst
for more details check man pages: "man systemd.service"

systemctl enable works but systemctl --user enable does not

I have a DO droplet running Ubuntu 16.04.1x64 and I'm trying to run IPFS as a systemd service. I've gone ahead and created a user "connor" and installed IPFS following the instructions here. I'm storing the service as "ipfs.service" in ~/.config/systemd/user/ipfs.service which looks like this:
[Unit]
Description=IPFS Daemon
[Service]
Type=simple
ExecStart=/usr/local/bin/ipfs daemon
ExecStop=/usr/bin/pkill ipfs
Restart=always
User=Connor
[Install]
WantedBy=default.target
What's odd is that if I run systemctl --user start ipfs it starts up just fine. However, running systemctl --user daemon-reload and then
systemctl --user enable ipfs I get the error:
Failed to execute operation: No such file or directory
However, if I run systemctl enable /home/connor/.config/systemd/user/ipfs.service -f it runs just fine. I can reboot and run IPFS commands just fine. I'd like to run it as a user though, and would also like to understand what I'm doing wrong.
Please, check that you are executing the commands with connor user, you may run whoami to see the user executing the command. (running the command with sudo changes the user to root)
In addition, I see that the user in the service file is capitalized (Connor instead of connor), this could bring other problems, and it is not needed, as a simple configuration like the one proposed by Arch Linux wiki works for user daemons.
Please find bellow the configuration I used for my ipfs daemon, (without User= and with a different Restart=, since Restart=always gave me problems while starting the daemon):
[Unit]
Description=IPFS daemon
After=network.target
[Service]
ExecStart=/usr/local/bin/ipfs daemon
Restart=on-failure
[Install]
WantedBy=default.target

respawn service Debian Jessie without inittab

I've installed the last stable version of Debian (Jessie) and /etc/inittab doesn't exist. I have read the new init system is called Sysv.
I need to launch a service with parameter, I used to add a line in inittab like
u1:23:respawn:/etc/init.d/my_service foreground
I'm trying to add this one with sysvrc-conf -p but I don't know how...
How can I do that without inittab?
Thank you so much.
Found this question by google, maybe someone else finds this usefull: The new init system for Debian Jessie is systemd. The old way in Debian Wheezy was Sysv with /etc/inittab.
To create a respawn service with systemd just create a file in /etc/systemd/system/ i.e. mplayer2.service
[Unit]
Desription=mplayer with systemd, respawn
After=network.target
[Service]
ExecStart=/usr/bin/mplayer -nolirc -ao alsa -vo null -really-quiet http://stream.sunshine-live.de/hq/mp3-128/Facebook-og-audio-tag/
Restart=always
[Install]
WantedBy=multi-user.target
and activate it
systemctl enable mplayer2.service
reboot or start it manually
systemctl daemon-reload
systemctl start mplayer2.service
If you reboot or kill the process, it will be restarted automatically some seconds later.