4

I'm trying to get my nodejs app to start on boot. It runs fine if I start it from the command line as the user odroid.

Here is my service file:

[Unit]
Description=ProImage
After=network.target mysql.service

[Service]
ExecStart=/bin/node /proimage/app.js
Restart=on-failure
RootDirectory=/proimage
WorkingDirectory=/proimage
User=root

[Install]
WantedBy=multi-user.target

When I run:

sudo systemctl status proimage_daemon

I get:

odroid@odroid:~$ sudo systemctl status proimage_daemon
● proimage_daemon.service - ProImage
   Loaded: loaded (/lib/systemd/system/proimage_daemon.service; enabled; vendor preset: enabled)
   Active: inactive (dead) (Result: exit-code) since Tue 2019-02-26 09:45:30 EST; 6s ago
  Process: 30797 ExecStart=/bin/node /proimage/app.js (code=exited, status=200/CHDIR)
 Main PID: 30797 (code=exited, status=200/CHDIR)

Feb 26 09:45:29 odroid systemd[1]: proimage_daemon.service: Unit entered failed state.
Feb 26 09:45:29 odroid systemd[1]: proimage_daemon.service: Failed with result 'exit-code'.
Feb 26 09:45:30 odroid systemd[1]: proimage_daemon.service: Service hold-off time over, scheduling restart.
Feb 26 09:45:30 odroid systemd[1]: Stopped ProImage.
Feb 26 09:45:30 odroid systemd[1]: proimage_daemon.service: Start request repeated too quickly.
Feb 26 09:45:30 odroid systemd[1]: Failed to start ProImage.

I've looked at journalctl using:

journalctl -u proimage_daemon.service

and it gives me the same the following:

odroid@odroid:~$ journalctl -u proimage_daemon.service --since 09:38
-- Logs begin at Tue 2019-02-26 09:02:47 EST, end at Tue 2019-02-26 10:02:34 EST. --
Feb 26 09:38:12 odroid systemd[1]: proimage_daemon.service: Trying to enqueue job proimage_daemon.service/stop/replace
Feb 26 09:38:12 odroid systemd[1]: proimage_daemon.service: Installed new job proimage_daemon.service/stop as 13040
Feb 26 09:38:12 odroid systemd[1]: proimage_daemon.service: Enqueued job proimage_daemon.service/stop as 13040
Feb 26 09:38:12 odroid systemd[1]: proimage_daemon.service: Job proimage_daemon.service/stop finished, result=done
Feb 26 09:38:12 odroid systemd[1]: Stopped ProImage ICU.
Feb 26 09:39:19 odroid systemd[1]: Started ProImage ICU.
Feb 26 09:39:19 odroid systemd[1]: proimage_daemon.service: Main process exited, code=exited, status=200/CHDIR
Feb 26 09:39:19 odroid systemd[1]: proimage_daemon.service: Unit entered failed state.
Feb 26 09:39:19 odroid systemd[1]: proimage_daemon.service: Failed with result 'exit-code'.
Feb 26 09:39:19 odroid systemd[1]: proimage_daemon.service: Service hold-off time over, scheduling restart.
Feb 26 09:39:19 odroid systemd[1]: Stopped ProImage ICU.

I've looked at a dozen posts about this problem. They all say status=200/CHDIR indicates a problem with the working directory.

In my case, the working directory definitely exists and it is owned by root. I've set the permissions to 777 recursively on this directory. I've tried lots of different things with the service file, all to no avail.

Does anyone have a suggestion as to what may be my problem?

  • what's your goal with setting RootDirectory? It's akin to a chroot, and it means that systemd is trying to change to /proimage/proimage... – Jeff Schaller Feb 26 at 15:17
  • @JeffSchaller I inherited this service file, so I was trying to get it to run. After deleting the RootDirectory line, the service started! Thanks for you comment. – cce1911 Feb 26 at 15:24
  • So, you're running random chmod -R 777s, and running a nodejs service as root? Sounds like a security disaster waiting to happen... – marcelm Feb 26 at 20:33
10

Per the systemd exec documentation, setting RootDirectory is akin to a chroot. In combination with setting WorkingDirectory, it means that systemd is chrooting your app to /proimage and then attempting within that directory to cd /proimage, which would translate to /proimage/proimage.

If you don't need to chroot the process, eliminate the RootDirectory directive. If you intend to chroot the process, eliminate the WorkingDirectory directive.

  • 1
    ... If you're running a nodejs application as root then chrooting is not an unnecessary precaution. – Shadur Feb 26 at 17:58
  • I should add that there's a third option where /proimage/proimage exists; then you could use both directives. – Jeff Schaller Feb 26 at 17:59
  • 1
    @JeffSchaller But then you need a /bin/node inside the /proimage root and also all needed libraries and support files. – filbranden Feb 28 at 3:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.