Ubuntu runners with Upstart init system

[tdbaldwin]

I'm working with the ECS runner provider and trying to understand the resulting configured image. Once in use, the configured runners have the Upstart init system. I'd expect that these runners would use systemd instead, which ubuntu switch over to as default in 15.04. my current configuration of the runner is minimal, only specifying the x86 and ARM architectures - all other EcsRunnerProvider.imageBuilder props are default. Not seeing anything obvious in this code that would cause the configuration to be set to upstart.

in the github action workflow, I'm running ps -p1 | grep systemd && echo systemd || echo upstart to check and it returns upstart

subsequently running a systemd command gives the error System has not been booted with systemd as init system (PID 1). Can't operate.

[kichik]

The runner itself is running inside a Docker container on the ECS machine. The container is single-use so it's deleted once the runner finishes the job. It's using the public.ecr.aws/lts/ubuntu:22.04 image by default. So the runner doesn't have systemd or upstart.

What systemd command are you trying to run?

[tdbaldwin]

thanks, I appreciate the extra context. supporting a dated build that calls systemctl start xyz.service. this currently works with our usage of github-hosted runners. if i'm understanding correctly 😅 , we'd need to either use ec2-based runners instead or update this part of the build in order to migrate.

[kichik]

All of our providers are on-demand. EC2 might give you access to systemctl, but the instance will be immediately shut down after the job is over. A new job will trigger the creation of a completely separate EC2 instance that won't have anything of the old instance saved.

If it's for scheduled builds, why not schedule? For example:

cdk-github-runners/.github/workflows/upgrade-main.yml

Lines 4 to 7 in 5bb58e4

	on:
	workflow_dispatch: {}
	schedule:
	- cron: 0 0 * * 1

[tdbaldwin]

yeah, the build's current usage of systemctl is spinning up an infrastructure dependency, one that we should update anyways to use docker instead. was hoping to minimize changes for migration but this seems like a worthwhile improvement anyways. appreciate your help!