Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Systemd user units #17

Open
TobiasSchaffner opened this issue Feb 17, 2022 · 9 comments
Open

Systemd user units #17

TobiasSchaffner opened this issue Feb 17, 2022 · 9 comments

Comments

@TobiasSchaffner
Copy link

At the moment it is not possible to install a systemd user unit. I am missing an option in package.metadata.deb.systemd-units that allows to define that the service should be installed for users.

I am not an expert with debian packaging but I am willing to implement it if I get some help.

From my point of view the following points have to be considered when an user option is enabled:

  • install service to /usr/lib/systemd/user/
  • call deb-systemd-helper, systemctl and deb-systemd-invoke with --user
  • systemctl and deb-systemd-invoke have to be called with the correct user and XDG_RUNTIME_DIR has to be set. (This is a bit cumbersome and only allows to start the service for the currently active user. Are there any other options?)

Any opinions on this?

I got it working with the following scripts:

postinst:

# Automatically added by cargo-deb
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
	# This will only remove masks created by d-s-h on package removal.
	deb-systemd-helper --user unmask service >/dev/null || true

	# was-enabled defaults to true, so new installations run enable.
	if deb-systemd-helper --user --quiet was-enabled time-tracker.service; then
		# Enables the unit on first installation, creates new
		# symlinks on upgrades if the unit file has changed.
		deb-systemd-helper --user enable service >/dev/null || true
	else
		# Update the statefile to add new symlinks (if any), which need to be
		# cleaned up on purge. Also remove old symlinks.
		deb-systemd-helper --user update-state service >/dev/null || true
	fi
fi

# End automatically added section
# Automatically added by cargo-deb
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
	if [ -d /run/systemd/system ]; then
		USER="$(who | head -1 | awk '{print $1;}')"
		runuser -l $USER -c "XDG_RUNTIME_DIR=/run/user/$(id -u $USER) systemctl --user daemon-reload >/dev/null || true"
		if [ -n "$2" ]; then
			_dh_action=restart
		else
			_dh_action=start
		fi
		runuser -l $USER -c "XDG_RUNTIME_DIR=/run/user/$(id -u $USER) deb-systemd-invoke --user $_dh_action service >/dev/null || true"
	fi
fi
# End automatically added section

prerm:

# Automatically added by cargo-deb
if [ -d /run/systemd/system ] && [ "$1" = remove ]; then
	USER="$(who | head -1 | awk '{print $1;}')"
	runuser -l $USER -c "XDG_RUNTIME_DIR=/run/user/$(id -u $USER) deb-systemd-invoke --user stop service >/dev/null || true"
fi
# End automatically added section

postrm:

# Automatically added by cargo-deb
if [ -d /run/systemd/system ]; then
	USER="$(who | head -1 | awk '{print $1;}')"
	runuser -l $USER -c "XDG_RUNTIME_DIR=/run/user/$(id -u $USER) systemctl --user daemon-reload >/dev/null || true"
fi
# End automatically added section
# Automatically added by cargo-deb
if [ "$1" = "remove" ]; then
	if [ -x "/usr/bin/deb-systemd-helper" ]; then
		deb-systemd-helper --user mask service >/dev/null || true
	fi
fi

if [ "$1" = "purge" ]; then
	if [ -x "/usr/bin/deb-systemd-helper" ]; then
		deb-systemd-helper --user purge service >/dev/null || true
		deb-systemd-helper --user unmask service >/dev/null || true
	fi
fi
# End automatically added section
@stappersg
Copy link
Contributor

I don't know what came first, https://github.com/kornelski/cargo-deb/blob/main/systemd.md or this issue. Thing I would like to known, is for which reason is this issue still open.

@ximon18
Copy link
Contributor

ximon18 commented Apr 2, 2023

This issue is open because it specifically concerns user units. It came after systemd.md.

The issue is that the currently generated shell fragments invoke systemd tooling without the —user argument and the reporter would like a way to benefit from the generated shell fragments but with this missing argument, without having to replace entire fragments by hand.

We should look at how the official Debian packaging tooling handles this.

@jchimene
Copy link

jchimene commented Jul 16, 2023

So the #DEBHELPER# substitution does work? I've had zero success with it. I susect the lack of tests to be a clue. I looked at the krill usage. I got some things from it.

The charming thing was the cargo-deb forced the inclusion of the #DEBHELPER# sentinel, then refused to perform the substitution.

I finally gave up and wrote the stanzas manually.

@ximon18
Copy link
Contributor

ximon18 commented Jul 16, 2023

It works, but there's too little information printed about what it is doing and too little support for investigating why it isn't doing what you expect when it doesn't seem to work.

Back when this was first implemented cargo-deb had very limited support for logging. I believe that since changed so I would very much like to improve this, the problem is finding time to do it.

@jchimene
Copy link

jchimene commented Jul 16, 2023

I was just coming back top delete my reply.... I finally got a response from cargo deb that merits investigation. Thanks for your quick reply!

I've still learned a lot from this tool about building Rust on debian. I will look into the logging issue. It would certainly be nice to peek behind the curtain.

@ximon18
Copy link
Contributor

ximon18 commented Jul 16, 2023

Regarding the Krill example, that may not be the easiest example to learn from as it packages for DEB, RPM and Docker, on multiple architectures with cross-compilation and for multiple O/S versions, handled by Ploutos which invokes tools such as cargo-deb and cargo-generate-rpm.

@jchimene
Copy link

jchimene commented Jul 16, 2023

Agreed. I had originally written in that direction, but erased it after second thought.

Anyway :( I have to use source packaging, which means getting back to debian/rules

Just when I had cargo-deb working. Basically, I used it to generate postint, prerm, postrm, and deploy assets. There are two drawbacks: 1) I'm on arm64 trying to deploy to amd64; 2) I'm on Lima, so writing to the appropriate directories on Linux requires root:root, which ain't happening.

Basically, I'm trying for reproducible builds on a target machine. I've created .deb files locally for remote installation, but not reproducibly. So, after a few decades, I've had to immerse myself in the debian build framework. As I don't allow my toolchain to be heavily Debianized, I install the Rust toolchain from upstream; which means debian-cargo just isn't appropriate without a bunch of work.

I'd hoped to sidestep the whole heavy lift with cargo-deb, but that's not to be. Maybe cross-compiling for amd64 will help.

@ximon18
Copy link
Contributor

ximon18 commented Jul 16, 2023

arm64 -> amd64 with cross-compiling should work, we do the reverse.

I'm afraid I don't know what Lima is or what the issue regarding directory permissions is that you are referring to, or why you have to use source packaging (whatever that is)...

@jchimene
Copy link

I was hoping cross-compling would be straightforward to setup, but I couldn't get gcc:amd64 installed w/o removing the arm64 arch.
Lima is containerd on macos. I just realized how to better set up a dev box, so I finally got the .deb created by cargo deb to install.
source packaging is dpkg-source; which I'll use to send the source to the amd machine, build it via cargo deb, then install via dpkg.
Thanks for your interest!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants