Ship systemd unit file with unoserver

[WilliamDEdwards]

It's likely that the most common use case would be to run unoserver in the background as a daemon. Shipping a systemd file (either packaged or in the README) would allow users to easily implement this.

Adding systemd support to the code itself (such as sending READY=1 at start time) would allow for using systemd's full potential, i.e. by using the 'Notify' type.

[mara004]

It's likely that the most common use case would be to run unoserver in the background as a daemon.

unoserver loads the full libreoffice app into memory, which may not be generally desirable to do. Therefore, it should only be running as long as it is really needed. I don't think an automatically started background daemon is suitable for this case.

Adding systemd support to the code itself (such as sending READY=1 at start time) would allow for using systemd's full potential

unoserver code should clearly not require systemd, as it is intended to be a cross-platform library.

[WilliamDEdwards]

It's likely that the most common use case would be to run unoserver in the background as a daemon.

unoserver loads the full libreoffice app into memory, which may not be generally desirable to do. Therefore, it should only be running as long as it is really needed. I don't think an automatically started background daemon is suitable for this case at all.

Eh, isn't that's the whole idea?

Adding systemd support to the code itself (such as sending READY=1 at start time) would allow for using systemd's full potential

unoserver code should clearly not require systemd, as it is intended to be a cross-platform library.

It is not said anywhere that it should be required.

[mara004]

Eh, isn't that's the whole idea?

Not quite. The idea is to start unoserver when you need it, then convert a batch of files, and then stop it again. The listener mode is to avoid repeatedly starting/stopping LibreOffice for every single file, but this doesn't mean it is designed to be kept as background task all the time.

It is not said anywhere that it should be required.

A phrase like Adding systemd support to the code itself sounds a lot like systemd would be required, or at least that development would be centered towards Linux/systemd.

[WilliamDEdwards]

It is not said anywhere that it should be required.

A phrase like Adding systemd support to the code itself sounds a lot like systemd would be required, or at least that development would be centered towards Linux.

If the systemd notification socket is not available, messages should be discarded.

[regebro]

I don't know anything about systemd, and it's not high on my list of things to learn. So that would probably be a "no".

[WilliamDEdwards]

I don't know anything about systemd, and it's not high on my list of things to learn. So that would probably be a "no".

I can create a PR if it's welcome.

[regebro]

The problem with that is that it's hard to maintain if I don't understand it. So it's welcome, but I'm a bit worried it would be a wasted effort. But if it's a 10 minute job or so, then that would be great.

[WilliamDEdwards]

The problem with that is that it's hard to maintain if I don't understand it. So it's welcome, but I'm a bit worried it would be a wasted effort. But if it's a 10 minute job or so, then that would be great.

If you choose not to add systemd support to the code, it'd be something like:

[Unit]
Description=unoserver
After=network.target

[Install]
WantedBy=multi-user.target

[Service]
Type=simple
User=unoserver
Group=unoserver
ExecStart=/usr/local/bin/unoserver
Environment=PYTHONUNBUFFERED=true
Restart=on-failure
RestartSec=60

... but seeing as how the unoserver binary could be installed anywhere, this should be no more than an example.