servicer is a user-friendly Command Line Interface (CLI) tool designed to simplify service management on systemd, abstracting away the complexities of the systemd ecosystem. With an easy-to-use API comparable to popular tools like pm2, servicer empowers users to create, control, and manage services effortlessly.
servicer create index.js --start --enable
This will create a service index.js.ser.service in /etc/systemd/system as
gm folks, any updates? I was looking forward to launch the product with snap as the default install option, but am getting delayed. A ping would help, regards!
There’s a 7 day minimum waiting period for votes to be considered. I’m not in the reviewer team but they’d usually ask for the additional info:
Does your snap fit under a supported category here
Have you explored all the options available in strict? You should be able to perform file read/writes in /etc/systemd/system by using the System Files interface. There might be more nuance to it that I’m missing but it’s something that’s worth exploring whilst you wait for the classic request.
Thank you for the suggestion @James-Carroll. I updated my snapcraft.yaml this way to add a system-files plug and switched to strict confinement
name: servicer # you probably want to 'snapcraft register <name>'
base: core22 # the base snap is the execution environment for this snap
version: 0.1.2 # just for humans, typically '1.2+git' or '1.3.2'
summary: Simplify Service Management on systemd # 79 char long summary
description: A CLI tool for service management on systemd.
grade: stable # must be 'stable' to release into candidate/stable channels
confinement: strict # use 'strict' once you have the right plugs and slots
plugs:
etc-systemd-system:
interface: system-files
write:
- /etc/systemd/system
apps:
servicer:
command: bin/servicer
plugs: [home, etc-systemd-system]
parts:
servicer:
# See 'snapcraft plugins'
plugin: rust
source: .
build-packages: [cargo, rustc]
However when I install with sudo snap install servicer_0.1.2_amd64.snap --dangerous and run servicer status it gives me a PermissionDenied error-
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 13, kind: PermissionDenied, message: "Permission denied" }', src/handlers/handle_show_status.rs:113:51
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
servicer status reads files from etc/systemd/system. What am I missing?
The interface has been defined but it won’t be automatically connected, have you run sudo snap connect servicer:etc-systemd-system? System Files is untrusted by default and when installed with --dangerous you’d always need to connect the interfaces specifically.
If/When you upload this to the store, it’ll still trigger a mandatory review like classic has, but you’d be able to ask for the interface to be connected automatically via a store override (with similar review process), and again whilst I’m not on the review team, your apps entire purpose is to create these service files, it’d be much more likely to be given than classic itself.
Mind, what’s just struck me now is that having the ability to write these service files effectively gives you a sandbox escape route trivially, by just writing a service script that runs as root to do work outside the sandbox for you; which will probably weigh into things. But still better to be strict vs classic even then; and it makes your life easier since strict snaps are generally easier to deal with.
Thank you for prompt response @James-Carroll. sudo snap connect servicer:etc-systemd-system did the trick. Now my CLI is asking permission to use dbus. Fortunately there’s a dbus-interface which should work.
Seems like it is not possible to call org.freedesktop.systemd1 using the dbus interface. I updated snapcraft.yaml like this-
name: servicer # you probably want to 'snapcraft register <name>'
base: core22 # the base snap is the execution environment for this snap
version: 0.1.2 # just for humans, typically '1.2+git' or '1.3.2'
summary: Simplify Service Management on systemd # 79 char long summary
description: A CLI tool for service management on systemd.
grade: stable # must be 'stable' to release into candidate/stable channels
confinement: strict # use 'strict' once you have the right plugs and slots
plugs:
etc-systemd-system:
interface: system-files
write:
- /etc/systemd/system
dbus-org-freedesktop-systemd1:
interface: dbus
bus: system
name: org.freedesktop.systemd1
apps:
servicer:
command: bin/servicer
plugs: [home, etc-systemd-system, dbus-org-freedesktop-systemd1]
parts:
servicer:
# See 'snapcraft plugins'
plugin: rust
source: .
build-packages: [cargo, rustc]
Thanks for the request, and apologies for the time it has taken to get reviewed. Thanks also @James-Carroll for your help on this one. I absolutely agree that system-files is preferable to classic, and I think in this case we are quite unlikely to grant classic because servicer doesn’t fit within any of the supported categories.
system-files itself is a super-privileged interface, so at the very least we would have to perform publisher vetting before allowing it’s use, but as James points out, the particular directories requesting do allow for trivial sandbox escapes, so I’m also hesitant to advocate for this route.
Thanks for the heads up guys. I understand and shall explore another method for distribution. If you use pm2 or systemd at work do give servicer a spin. Would appreciate some early users. Regards!
