Is it sane to override launch.service if INITSYSTEM=on?

Product support
1

When using INITSYSTEM=on, Resin no longer restarts my main process when it crashes (it doesn’t restart the container either).

The systemd unit /etc/systemd/system/launch.service is pretty simple:

[Unit]
Description=Resin.io User Application

[Service]
EnvironmentFile=/etc/docker.env
ExecStart=/etc/resinApp.sh
StandardOutput=tty
StandardError=tty
TTYPath=/dev/console


[Install]
WantedBy=basic.target

If I want to add behaviors to this service, is it sane to just overwrite this file with a modified version? If I do that, what’s the likelihood of it breaking with future ResinOS updates?

If it’s considered a normal use case to override this service, it also might be good to document it alongside the INITSYSTEM=on docs.

Cheers :v:

2

Hi, can you paste your Dockerfile please?
And is this service you pasted here intended for the user container?

3

Hi @floion,

Is the Dockerfile actually relevant here? I meant this as a general question as to whether it’s considered a good or bad practice to override launch.service (the systemd unit that launches the user application, such as this one).

I’ve read in other forum posts that with INITSYSTEM=on, the container no longer gets restarted when the application crashes, and that this is expected behavior (here, for example). And in that specific post, @imrehg recommends overriding the application launch service, which I guess answers my question on whether it’s acceptable to do that.

In either case, it might be worth documenting all this stuff in the INITSYSTEM documentation: https://docs.resin.io/runtime/runtime/#init-system

4

I do believe this will get overwritten with application updates so it would not be safe to overwrite this service.
@nghiant2710 please correct me if I am wrong

5

I see, that’s what I was afraid of. So is there any officially supported way to ensure that my app gets restarted if it crashes, even when using INITSYSTEM=on?

6

@bgentry, you can override the launch.service without any problems at all. Moreover, you can add a new service if you don’t want to use the default service, just remember to enable by doing systemctl enable <service> in your Dockerfile.

7

Thanks, that’s great to know. Keep up the good work :slight_smile:

8

Hello, I have a similar interest to override the default launch behavior because I want these properties:

[Service]
Type=oneshot
Restart=no
RemainAfterExit=yes

The reason that I do this is that I want the entrypoint script to terminate completely and leave system to run my application as a separate unit file (which I set up in my entrypoint script), but to preserve the system status as healthy (graceful exit; do not attempt to restart entrypoint).

However, since updating two of my devices to Resin OS 2.13.6+rev1 (from 2.12 on a Pi2 and Pi3 device), the launch service fails very early after loading any new container. Simply starting the unit interactively works without error.

root@raspberry-pi2-0e771b3:~# journalctl -u launch
-- Logs begin at Thu 2018-08-09 22:09:35 UTC, end at Fri 2018-08-10 05:17:52 UTC. --
Aug 09 22:09:38 raspberry-pi2-0e771b3 systemd[1]: Starting Resin.io User Application...
Aug 09 22:09:39 raspberry-pi2-0e771b3 systemd[1]: launch.service: Main process exited, code=exited, status=1/FAILURE
Aug 09 22:09:39 raspberry-pi2-0e771b3 systemd[1]: Failed to start Resin.io User Application.
Aug 09 22:09:39 raspberry-pi2-0e771b3 systemd[1]: launch.service: Unit entered failed state.
Aug 09 22:09:39 raspberry-pi2-0e771b3 systemd[1]: launch.service: Failed with result 'exit-code'.
root@raspberry-pi2-0e771b3:~# systemctl start launch
root@raspberry-pi2-0e771b3:~# echo $?
0
root@raspberry-pi2-0e771b3:~# systemctl status launch
● launch.service - Resin.io User Application
   Loaded: loaded (/etc/systemd/system/launch.service; enabled; vendor preset: enabled)
  Drop-In: /etc/systemd/system/launch.service.d
           └─app_override.conf, override.conf
   Active: active (exited) since Fri 2018-08-10 07:18:58 SAST; 9min ago
 Main PID: 196 (code=exited, status=0/SUCCESS)
   CGroup: /docker/6d3b4774dfcbc88d5b33da59d7a439f1a3725fb9227d72ba74ad2244aeb4652c/system.slice/launch.service

...
Aug 10 07:18:58 raspberry-pi2-0e771b3 systemd[1]: Started Resin.io User Application.
root@raspberry-pi2-0e771b3:~#

For completeness, how are the relevant portions of my Dockerfile:

FROM resin/raspberry-pi2-debian:stretch
ENV INITSYSTEM on
...
# Resin systemd
COPY ./config/systemd.launch.service /etc/systemd/system/launch.service.d/app_override.conf

CMD ["/opt/app/entrypoint.sh"]

For my Pi3 I use FROM resin/raspberrypi3-debian:stretch.

Is there a way to get any more debugging information about why the launch service fails when launched upon container update? Just to emphasize, the launch service on both devices works as intended, without error if run interactively.

11

Just an update on this. When adding some debug logging to the top of my entrypoint script, my Pi3 device appears to be loading the entrypoint via the launch unit without any problems now (with the expected log message appearing).

Aug 10 16:15:15 raspberrypi3-6da19ce root: DEBUG: entrypoint reached!

I’ll report back on further problems if and when I see them.