tl;dr
Culprit: developer mode
I got it working. The .service file needed to be this:
/lib/systemd/system/ghost_domain-tld.service :
[Unit]
Description=Ghost systemd service for blog: domain.tld
Documentation=https://ghost.org/docs/
[Service]
Type=simple
WorkingDirectory=/srv/www/ghost/domain.tld
User=ghost
Group=ghost
Environment="NODE_ENV=production"
Environment="GHOST_NODE_VERSION_CHECK=false"
ExecStart=/usr/bin/ghost run
Restart=always
SyslogIdentifier=ghost_domain-tld
[Install]
WantedBy=multi-user.target
This was edited per discussion to remove:
StandardOutput=syslog
StandardError=syslog
Long story
No, this is the better, safer way.
There never was any Systemd, Nginx, or Node error to report; it just had a bad gateway on Nginx from the browser, but systemctl reported the service running just fine, which means the Nginx reverse proxy was pointing to a living .service that didn’t exist. mjw, ghost start and ghost install always throw errors up to 42,000 ft telling me that I can’t fly, despite cruising at 42,000 ft, so those warnings don’t report real problems anyway.
My problem seemed to be that developer mode didn’t like concurrent sessions. So, remove -D and all Ghosts run.
Why I made my own .service files…
I’m running Arch and MariaDB with the --db=mysql option, and I have absolutely no problems once it’s running. Arch keeps everything current, so “no newer than” version checks break everything that works anyway, and then won’t create that .service file, which was why I asked. This is a security issue…
From a SysAdmin’s seat, creating .service files is either my job or the job of a package manager like pacman or apt or apt-get or even dpkg. Systemd service creation is not the job of a non-root user running ghost install CLI commands.
Unix/Linux CLI = GUI API
…otherwise it’s not a bona fide CLI tool.
Web browsers don’t ask mouse users for the sudo password, so the CLI installer shouldn’t either. This isn’t DOS of the 1990s; there’s a reason awesome apps are build on Unix, including Apple’s.
No .service file should ever be created by a command that does not require sudo when run by a non-root user.
“Please enter sudo password” in the middle of the install process = ductape bodywork → can’t hold water.
The safer workflow is that all changes to hosted websites or system settings require sudo or “run as root” up front, then have their scripts employ system users or otherwise handle permissions like “compiling as non-root”—all handled inside the CLI tool.
25% faster rollout
Ghost could be rolling out their new feature roadmap 25% faster if the CLI workflow were in order. Seeing things orchestrated this way tells me that the Ghost code team kept bumping into mirrors in a mirror maze. The problem is that the 50 year old SysAdmin curmudgeons don’t want to talk to the Node & JS masters to help perfect what the Ghost guys are doing. I see what the Ghost team is trying to do, and I like it. I just wish they knew they could do it 25% faster like I know they can.
Ghost runs happy as Larry on Arch with MariaDB, just like almost everything else that runs on Debian. All these “can’t use the new version that works, can’t use Monty’s current SQL database” warnings aren’t needed. I have it clipping along just fine. So, yes I wrote my own .service file because that’s what Self-hosting Developers do when a non-sudo command asks for a sudo password after execution.
It took two weeks, but I got Ghost working again, just like I did 6 years ago. I like what the team’s been up to.
Ghost is awesome, both in the browser and in the RAM. I hope future releases don’t require what I don’t need. I’m done with WordPress, if I’m allowed to be.