my-systemd

Find the systemd services you created and forgot the names of.

systemctl에 뭐라고 올렸는지 까먹었을 때, 내가 만든 서비스만 보여주는 CLI.

my-systemd is a tiny npm CLI for VPS, home server, and side-project operators who create their own systemd services and later forget the exact service names.

The whole UX

Install once:

npm i -g my-systemd

Then just run:

my-svcs

That is the main product. It lists the systemd services that look like yours.

No global install? This also works:

npx my-systemd

Tiny commands

my-svcs             # list your systemd services
my-svcs failed      # only failed ones
my-svcs running     # only running ones
my-svcs abc         # search name/path/description
my-svcs logs abc    # recent logs for abc.service
my-svcs doctor      # quick failed/suspicious report
my-svcs group       # manage saved service groups

Advanced, only if you need it:

my-svcs --user      # only ~/.config/systemd/user/*.service
my-svcs --system    # only /etc/systemd/system/*.service
my-svcs all         # include generated/vendor-like local files too
my-svcs --json      # machine-readable output

The package-name command also works:

my-systemd

Example output:

#  NAME                 STATE   ENABLED   SCOPE   PATH
1  abc-1234.service     active  enabled   system  /etc/systemd/system/abc-1234.service
2  old-worker.service   failed  disabled  user    ~/.config/systemd/user/old-worker.service

The same service filename can appear twice when you have both a system unit and a user unit with that name. The SCOPE column tells you whether each row is the system unit or the user unit.

Groups

Create a group from the current numbered list:

my-svcs
my-svcs group create web @1 @4 @5

Numbers like @1 are selection shortcuts only. my-systemd stores explicit service ids like system:abc.service and user:worker.service in ~/.config/my-systemd/groups.json, so the group does not depend on list numbers staying the same later. #1 is accepted only if your shell passes it through, but @1 is the recommended form because # starts comments in common shells.

You can also add, remove, inspect, or delete only the saved group definition:

my-svcs group add web @7
my-svcs group drop web @4
my-svcs group show web
my-svcs group status web
my-svcs group doctor web
my-svcs group delete web

If group drop makes a group empty, it asks before deleting the empty group:

Delete empty group? [y/N]

group delete removes only the saved group definition. It does not delete, stop, disable, or edit any systemd service.

Grouped service controls are dry-run by default:

my-svcs group start web
my-svcs group stop web
my-svcs group restart web

Use --yes only when you want to execute the matching systemctl calls:

my-svcs group restart web --yes

Uninstall

Remove the package:

npm uninstall -g my-systemd

That removes the my-svcs and my-systemd commands. Saved groups are user data and stay in ~/.config/my-systemd/groups.json. Remove them too only if you no longer want the saved group definitions:

rm -rf ~/.config/my-systemd

What it looks at

It focuses on local service files:

• system scope: /etc/systemd/system/*.service
• user scope: ~/.config/systemd/user/*.service

It intentionally ignores distro/vendor units from places like /lib/systemd/system and /usr/lib/systemd/system.

By default it also hides common generated/vendor-like files that can appear in local directories, such as snap.*.service and dbus-org.*.service. Use my-svcs all or my-svcs --all if you want those too.

Why not just systemctl list-units?

systemctl list-units is great, but it shows what systemd knows about right now — including lots of distro services. my-systemd starts from the places where people usually put their own units, then asks systemd for status.

That makes the default answer closer to:

“What did I put in systemd again?”

not:

“What exists in systemd?”

Safety boundary

my-systemd is lookup-first.

Listing, logs, doctor, and group edits do not change systemd services. group delete and group drop only change the saved group config. group start, group stop, and group restart print a dry-run plan unless you pass --yes.

It does not enable, disable, edit, or remove services.

Requirements

• Linux with systemd
• Node.js 20+

On machines without systemd, my-systemd prints a friendly unavailable status instead of pretending to manage anything.

Development

npm test
npm run build
node bin/my-systemd.js --help
npm pack --dry-run

The implementation has no runtime dependencies and uses Node's built-in test runner.