systemd Service File Generator

Almost always because ExecStart is not an absolute path. systemd executes the binary directly rather than through a shell, so it never searches $PATH; a bare node server.js means "run a file literally named node in the root of the filesystem". Use the output of which node. The same code appears when the file exists but is not executable, or when its interpreter line points at a missing interpreter, so check chmod +x and the shebang if the path is already absolute.

No, and systemd will not complain — it just passes them to your program as ordinary arguments, so myapp > /var/log/app.log starts myapp with three arguments and no redirect. If you genuinely need shell syntax, invoke a shell explicitly with ExecStart=/bin/sh -c 'myapp | tee /var/log/app.log'. In most cases you do not need it: stdout already goes to the journal, so read it with journalctl -u yourapp instead of redirecting to a file.

After= is ordering only: it says "if both units start in the same transaction, start mine second". It does not pull the other unit in, so After=network-online.target alone on a machine where nothing else wants that target means the target is never activated and you wait for nothing. Wants= is the dependency that actually pulls it in. That is why this generator emits Wants=network-online.target alongside the After= line — it is the pair the systemd documentation recommends, and the most common cause of a service starting before the network is up.

Use a system unit for anything that must be running before or without a login — a web server, a database, a scheduled job. Use a --user unit for something tied to your session, such as a syncing agent or a personal bot; it runs as you, needs no sudo, and lives in ~/.config/systemd/user. The catch is that a user manager normally stops when your last session ends, so a user service that should survive logout needs loginctl enable-linger, which the generated commands include. User units also cannot set User= or Group=, and system targets such as network-online.target do not exist in the user manager.

It is safe to try, but not safe to assume. ProtectSystem=strict makes the whole filesystem read-only apart from /dev, /proc and /sys, so a service that writes a PID file, a SQLite database or a log outside its working directory will fail once you enable it. The generator adds ReadWritePaths for the working directory precisely so the common case still works; anything else the service writes to has to be listed there as well. If the service breaks the moment you add the block, remove lines one at a time rather than dropping all of them — systemd-analyze security yourapp.service will score the result and tell you what each directive buys.

systemd caches unit files, so an edit on disk is invisible until you run systemctl daemon-reload (or systemctl --user daemon-reload for a user unit). After the reload you still need systemctl restart yourapp for a running service to pick up the new configuration — daemon-reload only reloads systemd's own view of the file. If a change to Environment= appears to be ignored even then, check whether an EnvironmentFile= is setting the same variable, since the file is read after the inline directives and wins.