how to install binary as a service in ubuntu - just getting errors

[bamboowonder]

Hi there,

I don't have or want docker, so I'm attempting to use the binary as a service on ubuntu 20.04
I found this: https://github.com/knadh/listmonk/blob/master/listmonk@.service
and tried to adapt it to setup the binary as a service but it continues to fail.

I moved the config to /etc/listmonk and the binary to /usr/bin

after enabled, daemon-reload, start are run, I get this in the log:
`
sudo systemctl status listmonk.service
● listmonk.service - listmonk mailing list and newsletter manager ()
Loaded: loaded (/etc/systemd/system/listmonk.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sun 2022-06-19 15:06:53 PDT; 4min 44s ago
Condition: start condition failed at Sun 2022-06-19 15:11:35 PDT; 2s ago
└─ ConditionPathExists=/etc/listmonk/.toml was not met

Jun 19 15:06:53 send systemd[1]: listmonk.service: Control process exited, code=exited, status=203/EXEC
Jun 19 15:06:53 send systemd[1]: listmonk.service: Failed with result 'exit-code'.
Jun 19 15:06:53 send systemd[1]: Failed to start listmonk mailing list and newsletter manager ().
Jun 19 15:06:53 send systemd[1]: listmonk.service: Scheduled restart job, restart counter is at 5.
Jun 19 15:06:53 send systemd[1]: Stopped listmonk mailing list and newsletter manager ().
Jun 19 15:06:53 send systemd[1]: listmonk.service: Start request repeated too quickly.
Jun 19 15:06:53 send systemd[1]: listmonk.service: Failed with result 'exit-code'.
Jun 19 15:06:53 send systemd[1]: Failed to start listmonk mailing list and newsletter manager ().
Jun 19 15:11:32 send systemd[1]: /etc/systemd/system/listmonk.service:48: Invalid device node path 'False', ignoring.
Jun 19 15:11:35 send systemd[1]: Condition check resulted in listmonk mailing list and newsletter manager () being skipped.
`

It seems like it is expecting variables to be passed in
ConditionPathExists=/etc/listmonk/.toml
which should be config.toml but in the file is %i.toml

Any insight about the correct way to install as a service would be appreciated.

Thank you,

[bamboowonder]

I ended up simplifying it greatly following this guide: https://betterprogramming.pub/unleashing-your-daemons-creating-services-on-ubuntu-731cd933e02e?gi=ff4c4fb9dc0a

It works now.

But I'd love to know if the service file can be installed as it appears to lock things down better.

[knadh]

Your service file (following that tutorial) should work just fine!

[MaximilianKohler]

This worked for me, but I had to add PermissionsStartOnly=true to [Service].

I'm getting AxiosError: Request failed with status code 504 when trying to upload a file (small jpg). And importing subscribers works but takes unusually long.

I used echo $HOME to find where it's creating the ${HOME}/uploads folder. For me it was /root/uploads, so I added that to the /admin/settings -> Media uploads -> Upload path.

I checked my firewall logs and don't see any blocks when I try to upload. I also set the uploads folder permissions to 777.

In the https://github.com/knadh/listmonk/blob/master/listmonk@.service file it has:

# Make /home/, /root/, and /run/user/ inaccessible.
ProtectHome=True

So I tried commenting that out and restarting systemctl daemon-reload and I see a bunch of errors that didn't show before:

systemctl status listmonk
Dec 01 02:49:40 centos7test systemd[1]: [/etc/systemd/system/listmonk.service:24] Not an absolute path, ignoring: %S/listmonk-
Dec 01 02:49:40 centos7test systemd[1]: [/etc/systemd/system/listmonk.service:45] Unknown lvalue 'ProtectControlGroups' in section 'Service'
Dec 01 02:49:40 centos7test systemd[1]: [/etc/systemd/system/listmonk.service:46] Unknown lvalue 'ProtectKernelTunables' in section 'Service'
Dec 01 02:49:40 centos7test systemd[1]: [/etc/systemd/system/listmonk.service:50] Invalid device node path 'False'. Ignoring.
Dec 01 02:49:40 centos7test systemd[1]: [/etc/systemd/system/listmonk.service:52] Unknown lvalue 'RestrictNamespaces' in section 'Service'
Dec 01 02:49:40 centos7test systemd[1]: [/etc/systemd/system/listmonk.service:54] Unknown lvalue 'RestrictRealtime' in section 'Service'
Dec 01 02:49:40 centos7test systemd[1]: [/etc/systemd/system/listmonk.service:59] Unknown lvalue 'MemoryDenyWriteExecute' in section 'Service'
Dec 01 02:49:40 centos7test systemd[1]: [/etc/systemd/system/listmonk.service:61] Unknown lvalue 'LockPersonality' in section 'Service'
Dec 01 02:49:40 centos7test systemd[1]: [/etc/systemd/system/listmonk.service:65] Unknown lvalue 'ProtectKernelModules' in section 'Service'
Dec 01 02:49:40 centos7test systemd[1]: [/etc/systemd/system/listmonk.service:68] Unknown lvalue 'PrivateUsers' in section 'Service'

I ran systemctl restart listmonk then systemctl status listmonk again and the errors don't show. And the file uploaded! And subscriber imports are back to normal speed...

If I run systemctl daemon-reload and then systemctl status listmonk the errors show. I wonder if those values are actually bad and I should remove them or if it's just because you're supposed to run systemctl restart listmonk after systemctl daemon-reload?

I searched one of the errors and found this https://bugzilla.redhat.com/show_bug.cgi?id=1975343, which says to use yes|no instead of true|false. I tried ProtectControlGroups=Yes and ProtectControlGroups=on but it still showed the error.

This says the version of systemd is just too old systemd/systemd#28492.

I changed ${HOME}/uploads to listmonk/uploads and that allowed me to enable ProtectHome=True, but it also seemed to slow down contact imports again. And even after commenting it out again uploads are still slow. Hmm, but then it was fast again the next time I tried, so maybe it's not related to ProtectHome=True.

I see that @runningnoodle and @kmohrf edited the file, so I'm tagging them to see what they know.

Also, I don't know if this can be fixed but it doesn't work to upload directly to /root/uploads. It would be nice if we could.

[kmohrf]

I don’t know which versions of systemd actually provide these config options, but given that I wrote the unit 2.5 years ago I’d say: anything that is not ancient should work. Which version of systemd are you using (systemctl --version)?

Edit: Just as a ballpark guess: PrivateUsers was introduced in systemd v232 which was released March 12, 2017. If you’re running a systemd that old, you might want to upgrade :).

[MaximilianKohler]

systemctl --version
systemd 219

I looked up how to upgrade systemd and people say to not mess with it (eg). Seems to be mostly hard coded to CentOS 7.

I'm thinking about doing a PR that:

• implements these changes
• adds a plus sign to ExecStartPre=+
• changes ${HOME}/uploads to listmonk/uploads given that ${HOME}/uploads is incompatible with ProtectHome=True.

EDIT: Nvm the + sign, commenter says it only works with the latest systemd, so I'll put PermissionsStartOnly=true to [Service] for now.

[MaximilianKohler]

Any reason to not include them all (files & folders) in the same location? Such as moving uploads to /etc/listmonk/:

ConditionPathExists=/etc/listmonk/config.toml
ExecStartPre=/usr/bin/mkdir -p "/etc/listmonk/uploads"

Also, I'm not sure how to add a static directory to this? Would it be something like:

ExecStartPre=/usr/bin/listmonk --static-dir /etc/listmonk/static/

Would it require another ExecStart= line? Just:

ExecStart=/usr/bin/listmonk --static-dir /etc/listmonk/static/

Or does there need to be something $SYSTEMD_LISTMONK_ARGS at the end of that?

[kmohrf]

When I said you might want to upgrade I didn’t mean systemd itself, but the OS itself. CentOS 7 has almost served its absolutely mind-boggling 10 year lifespan. Its EOL is mid-2024. You need to find an upgrade path for that. I’m updating my Debian every 2 years and feel like a preservationist already.

Any reason to not include them all (files & folders) in the same location? Such as moving uploads to /etc/listmonk/

Yes. Decades of convention and standardization of application packaging :). man file-hierarchy gives an introduction.

To be frank: I’ve provided the systemd unit so that it can serve as a starting point for users (like you) and people doing packaging (like me). It’s ok to take and modify it to your needs. You don’t need a template unit? That’s fine. You want to deactivate features so that the unit runs on systemd 219? That’s also fine. But I don’t think you’re doing anyone a favor if you try to upstream these changes. Most of us aren’t on systemd 219. The unit should run fine on most systems.

[MaximilianKohler]

Yes, I don't think any of the changes I proposed were "to deactivate features so that the unit runs on systemd 219". I ignored those errors since they didn't seem to have an impact. The changes I've proposed seem to be broad ones. I'll list them again:

1. The changes from this guide, which fix this OP's (@bamboowonder) issue.
2. Add PermissionsStartOnly=true to [Service], which is required.
3. Change ${HOME}/uploads to listmonk/uploads given that ${HOME}/uploads is incompatible with ProtectHome=True.
4. Add commands to create a static dir. https://listmonk.app/docs/templating/#system-templates

[kmohrf]

Did you test the existing unit on a modern OS (anything from the past ~3 years) to get a feeling which errors might be caused by the old version of systemd?

1. See Update listmonk@.service #1614.

2. PermissionsStartOnly has been deprecated since systemd v240. That’s what the command prefixes are for.

3. Do you have an explanation why ProtectHome should be "incompatible" with ${HOME}/uploads when the HOME variable doesn’t reference a directory in /root, /home or /run/user?

[MaximilianKohler]

Did you test the existing unit on a modern OS (anything from the past ~3 years) to get a feeling which errors might be caused by the old version of systemd?

I am not able to do that yet (I'll be moving from Centos7 to AlmaLinux next year). But given that @bamboowonder and the author of that guide both had the same issues, they seem to impact a good percentage of people who are trying to use this.

PermissionsStartOnly has been deprecated since systemd v240. That’s what the command prefixes are for.

Yes, but as I noted, the + signs only work on newer versions of systemd and the depreciated command still works on all systems. Perhaps in a year or so we can switch from PermissionsStartOnly=true to ExecStartPre=+, but for now it seems best to use the command that works for everyone.

when the HOME variable doesn’t reference a directory in /root, /home or /run/user?

I'm not familiar with the default home directory for various linux installations, but on my machine the default was /root/, and I suspect that /root/ and /home/ would be the most common default directories. So unless someone changed their ${HOME} directory using ${HOME} as default would probably cause the same error for many/most people.

It also arguably adds an unnecessary level of complexity for people who don't know what/where their ${HOME} directory is.

EDIT: I was thinking that we could possibly have two versions of the file or even two sets of commands in the same file and comment one of them out and add more notes/comments about each set in the file.