Provide config to run pm2 via systemd user instance

[Genda1ph]

Hello,

pm2 can run just fine under systemd --user instance. It even auto-starts properly, provided you enable session lingering.

Here's the config I'm using:

[Unit]
Description=PM2 process manager
Documentation=https://pm2.keymetrics.io/
After=network.target

[Service]
TimeoutStartSec=8
Environment=PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin PM2_HOME=/home/deploy/.pm2 PM2_API_IPADDR=127.0.0.1
Restart=always
RestartSec=8

ExecStart=/usr/bin/pm2 resurrect --no-daemon
ExecReload=/usr/bin/pm2 reload all
ExecStop=/usr/bin/pm2 kill

[Install]
WantedBy=multi-user.target

This way it inherits all limits imposed on user it's running under and works just fine.

As a side note: it would be much better if we could make API listen on UNIX domain socket, this would allow to place pm2 user's sockets under, say /run/pm2/$uid.sock and externally monitor those apps (via Nagios or something) without looking for spare TCP port.

[vmarchaud]

You can already register a systemd service by running and following pm2 startup systemd, the daemon will run as the same user than you run the pm2 startup command. (see template of unit file)
The socket files are stored inside PM2_HOME, so i dont get what you talking about with the TCP port ?

[Genda1ph]

This is different: pm2 attempts to register as a service in global systemd config, in /etc/systemd/system, which requires root privileges to set up (both for writing config and for daemon-reload, I haven't tested if user is capable of restarting the system service).

However, for each user session there is a personal systemd --user instance. It's configs are stored in $HOME/.config/systemd. Services/targets/timers are stored under $HOME/.config/systemd/user.

Installing and controlling these does not require root privileges at all, they're completely isolated under user's slice with all limitations. This is much better in most cases.

I suggest providing both configs - local and global and let users use what suits their needs best.

As for ports: running pm2 web takes up a TCP port for web API and if you run more than one instance of pm2, you have to look for a free ADDRESS:PORT pair for each web API instance. It would be much easier to just use UNIX domain socket to communicate with the API when running multiple instances of pm2 web.

Also, our dev who uses pm2 told me that web API should be able to run on UNIX domain socket, but I had no luck trying to use it.

[vmarchaud]

There isn't any web API for PM2, we use a custom protocol over socket to communicate with the daemon.
You already opened an issue to expose pm2 web over socket which is just a http server printing statistics, again, not an API.

I'll open a clear issue for systemd --user too.

[Genda1ph]

Thanks

[knoxcard]

Isn't it better to run the service as root and specify the user and/or group inside the service file?

[Service]
User=pm2
Group=pm2

[Unit]
Description=PM2 process manager
Documentation=https://pm2.keymetrics.io/
After=network.target

[Service]
User=pm2
Group=pm2

TimeoutStartSec=8
Environment=PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin PM2_HOME=/home/deploy/.pm2 PM2_API_IPADDR=127.0.0.1
Restart=always
RestartSec=8

ExecStart=/usr/bin/pm2 resurrect --no-daemon
ExecReload=/usr/bin/pm2 reload all
ExecStop=/usr/bin/pm2 kill

[Install]
WantedBy=multi-user.target

[Genda1ph]

Running pm2 as system instance would require elevated privileges to control it, hence per-user instancing is better in terms of isolation and dev control.
I just set it up and let the dev use it, without requiring sudo or anything.