I like the idea of this, will find something to run it on later.
Awesome, would really appreciate your feedback!
Show HN: Servicer, pm2 alternative built on Rust and systemd
21–30 of 41 posts
Re: Show HN: Servicer, pm2 alternative built on Rust and systemd
#22You might like systemd's run command, it's a hidden little gem that basically does what your tool does--it turns some CLI params into a transient service file: https://www.freedesktop.org/software/systemd/man/systemd-run... I dunno if this was a more recent addition to systemd, but it's pretty slick in my limited use. I use it for exactly the scenarios you mention, like quickly spinning up some local user services du…
TIL, Pretty cool!
But I suppose there isn't away to run these transient services as boot because they are definition gone after they have stopped?
Re: Show HN: Servicer, pm2 alternative built on Rust and systemd
#23Kudos for making it daemonless!
I think Servicer can be a good starting point for people to learn how to use Systemd services and systemd-run. Systemd is huge and can be scary to learn, so providing a set of steps to get a service running is very instructive.
But then, Servicer requires super user priviliges to modify the system, instead of running everything as the non-privileged user, via `--user` flag for systemctl or via systemd-run...
There are few commands to learn the basics when setting up a new system wide service: systemctl and journalctl. Some examples: - systemctl daemon-reload: reload all unit files - systemctl start/stop/status/restart : quite intuitive, don't you think? - journalctl -u : to see all logs from that service. I like to also use `-f` flag to follow new log entries. - man systemctl: the manual for systemctl - man journalctl: the manual for journalctl
Writing new service units is the "hard" part, but there are plenty of "templates" on the net, or you can browse `/usr/lib/systemd/system/` for examples.
But don't let the critics here demotivate you. You made a tool, you published it, congrats!
Re: Show HN: Servicer, pm2 alternative built on Rust and systemd
#24Earlier quoted context omitted.
The file's pretty cumbersome, honestly, since I usually don't remember the format or the best practices for it. Plus, sometimes there is no place to put them that isn't conflicting with the package manager, so "best practice" ends up being to make your own package containing the unit file, and ... I'm not a big fan of "best practices" in general, but it'll turn into a whole rabbithole if you let it. At least with a p…
FWIW, you can override unit files that are installed by a package manager: https://hsm.tunnel53.net/article/systemd/
I think the "issue" isn't the package manager overwriting your custom unit files, but rather just the litter of untracked files in places the package manager is supposed to be in charge of. Since some people want to be able to track those files, and prevent them from making a mess.
In practice I don't think it is a huge issue. I've just left unit files laying around on embedded devices without issue. Hard to find which ones are mine though, if I've lost my mental list of them.
(Also, writing one from scratch without a template is annoying, since I haven't memorized the format.)
Re: Show HN: Servicer, pm2 alternative built on Rust and systemd
#25Kudos for making it daemonless! I think Servicer can be a good starting point for people to learn how to use Systemd services and systemd-run. Systemd is huge and can be scary to learn, so providing a set of steps to get a service running is very instructive. But then, Servicer requires super user priviliges to modify the system, instead of running everything as the non-privileged user, via `--user` flag for systemct…
> Kudos for making it daemonless!
It uses the systemd daemon to manage the services. It's not clear what an additional service would do.
Re: Show HN: Servicer, pm2 alternative built on Rust and systemd
#26> Systemd on the other hand has most of the things I need, but I found it cumbersome to use Could you please expand on this? From what I understand, to use systemd to deploy a microservice is basically one file: # /etc/systemd/system/myservice.service [Unit] Description=My Microservice After=network.target [Service] ExecStart=/path/to/myservice Restart=always User=myuser Group=mygroup Environment=VARIABLE=value Worki…
The file's pretty cumbersome, honestly, since I usually don't remember the format or the best practices for it. Plus, sometimes there is no place to put them that isn't conflicting with the package manager, so "best practice" ends up being to make your own package containing the unit file, and ... I'm not a big fan of "best practices" in general, but it'll turn into a whole rabbithole if you let it. At least with a p…
This was solved from beginning of systemd with different directories for files mananged by package managers (under /lib), and files managed by you (under /etc). This is documented in `man systemd.unit`:
https://www.freedesktop.org/software/systemd/man/systemd.uni...
The same doc also describes a "drop-in" file format, where you can override just the details you want from a system file.
Re: Show HN: Servicer, pm2 alternative built on Rust and systemd
#27You might like systemd's run command, it's a hidden little gem that basically does what your tool does--it turns some CLI params into a transient service file: https://www.freedesktop.org/software/systemd/man/systemd-run... I dunno if this was a more recent addition to systemd, but it's pretty slick in my limited use. I use it for exactly the scenarios you mention, like quickly spinning up some local user services du…
Great tip. I would also couple it with the —-user flag so the service runs as your user. Stuff like this shouldn’t have root permissions anyway.
Typically the `User=` directive is used to specify what the user the service runs in.
There is still a benefit to requiring root to create the service file though: If the service is compromised when it's running as `User=`, it can't modify the systemd service file itself, which is owned by root.
Re: Show HN: Servicer, pm2 alternative built on Rust and systemd
#28> Systemd on the other hand has most of the things I need, but I found it cumbersome to use Could you please expand on this? From what I understand, to use systemd to deploy a microservice is basically one file: # /etc/systemd/system/myservice.service [Unit] Description=My Microservice After=network.target [Service] ExecStart=/path/to/myservice Restart=always User=myuser Group=mygroup Environment=VARIABLE=value Worki…
I built the tool simply to improve developer experience. Run `systemctl list-units` and the console is flooded with a wall of services, most of them are not mine. Run `ser status` and I only see the ones that I created. The activity state, CPU and memory usage is displayed so I don't need to run a separate command. hp@hp:~$ ser status +-----+-------------+----------+----------------+-------+--------+ | pid | name | a…
As long as remembering a new command is required this also be used:
* systemctl status 'brand-*' That is, custom services could start with the same prefix.
I run a lot of custom services, and usually I want to check on one specifically, or if I want to look at the total service health, I also want to include the services which are "not mine".
Re: Show HN: Servicer, pm2 alternative built on Rust and systemd
#29Kudos for making it daemonless! I think Servicer can be a good starting point for people to learn how to use Systemd services and systemd-run. Systemd is huge and can be scary to learn, so providing a set of steps to get a service running is very instructive. But then, Servicer requires super user priviliges to modify the system, instead of running everything as the non-privileged user, via `--user` flag for systemct…
Thanks for the feedback! I'm certainly add a `--user` flag. One kind note though, the service being set up does not have root access. The value of `User=` is $SUDO_USER (hp- my regular non privileged user that initiatiated sudo mode) instead of $USER (root). Sudo is needed for writing `.service` files to `/usr/` and for start, stop operations with dbus.
Re: Show HN: Servicer, pm2 alternative built on Rust and systemd
#30As someone who knows systemd very well, my team of Mac-based devs did appreciate when I made something like this. I used a different framework, a precursor to Tome:
https://github.com/toumorokoshi/tome
- my-cli help
- my-cli start
- my-cli stop
- my-cli restart
- my-cli status
So while my first reaction was "why not use systemd?", my second reaction is "Oh yeah, I built something like that and it was helpful".
Systemd is great, but it does have a massive amount of a commands and documentation and be overkill and overwhelming.