Feature Request - better support for running under systemd

[peterhoeg]

With the upcoming split between backend and frontend, it's likely that a user would want to run the backend under systemd. If that is the case, there are a few things maestral can do to make things nicer:

1. When running in the foreground, send a notification that it's up and running
2. Continuously update its status (using the same sd_notify mechanism), so that systemctl --user status maestral will return the current status in the status field ("Syncing X out of Y", "Up to date" etc)
3. Log to the journal instead of just stdout

Regd item 1, this means that systemd will only continue starting other services when maestral actively informs it that it is up and running. A use case would be the GUI running as a separate service under systemd that is dependent on the backup actually being up and running.

Regd item 2, we could avoid spamming the logs with "maestral.monitor INFO: Up to date" as it would simply just show the status in the status field.

Regd item 3, we currently get duplicated timestamps as journald captures the timestamp when the message was output to stdout and maestral also writes the time. Example:

Sep 08 21:55:59 mildred maestral[3444]: 2019-09-08 21:55:59 maestral.monitor INFO: Up to date

There are some python modules that can help with this:

• https://pypi.org/project/sdnotify/
• https://pypi.org/project/systemd/

[peterhoeg]

An example of the improved status (item 2):

emperor.uwsgi.service - uWSGI Emperor
 Loaded: loaded (/etc/systemd/system/emperor.uwsgi.service)
       Active: active (running) since Tue, 17 May 2011 08:51:31 +0200; 5s ago
Main PID: 30567 (uwsgi)
       Status: "The Emperor is governing 1 vassals"
       CGroup: name=systemd:/system/emperor.uwsgi.service
               ├ 30567 /root/uwsgi/uwsgi --ini /etc/uwsgi/emperor.ini
               ├ 30568 /root/uwsgi/uwsgi --ini werkzeug.ini
               └ 30569 /root/uwsgi/uwsgi --ini werkzeug.ini

[samschott]

Those are all good suggestions. Two possible issues that I see:

• Is there a way to detect if Maestral is started under systemd? If not, could there be any issues with always emitting such notifications, or logging to the journal? The "start-on-login" option of the GUI for instance creates a Desktop Entry "~/.config/autostart/maestral.desktop" and does not use systemd.

• It looks like python-systemd cannot directly be installed with pip without installing systemd-devel and other packages first. This would complicate the installation process for many people.

If the former is not an issue, and the latter can be circumvented, I am happy to review pull requests!

Regarding spamming the log with "Up to date" messages: You can raise the log level with for instance maestral log level WARNING. This will dramatically reduce the size of log files and will be the default in the next release. Or one can write a custom handler which ignores duplicate messages.

[peterhoeg]

Is there a way to detect if Maestral is started under systemd?

systemd v232 and above sets an $INVOCATION_ID environment variable

The "start-on-login" option of the GUI for instance creates a Desktop Entry "~/.config/autostart/maestral.desktop" and does not use systemd.

The user could always just delete that file (and disable autostart) if they want systemd to run it. Alternatively, the maestral.desktop could execute systemctl --user maestral.target and we then have a target that depends on 2 services: the backend and the GUI.

Regarding spamming the log with "Up to date" messages

That specific message is more of a status message rather than a log message imho. Again, that could be solved at least when running under systemd.

It looks like python-systemd cannot directly be installed with pip without installing systemd-devel and other packages first

According to https://github.com/systemd/python-systemd#installation :

This module should be packaged for almost all Linux distributions.

[samschott]

systemd v232 and above sets an $INVOCATION_ID environment variable

Perfect, that simplifies things. I see no direct conflict with the GUI's autostart function, it could either continue as is or use systemd on Linux.

That specific message is more of a status message rather than a log message imho.

It is. But the way Maestral is set up at the moment, it uses log messages to communicate its status. Anything of level INFO and higher is used to populate the status and will affect the appearance of the GUI. WARNING is typically used for sync issues. ERROR and higher indicates problems which prevent Maestral from continuing to function, such as a deleted Dropbox folder or revoked access. They will raise a blocking error dialog which the user must act upon.

In that system, "Up to date" is indeed a logging message of level INFO.

According to https://github.com/systemd/python-systemd#installation...

True. But it needs to be installed with the system's package manager instead of pip. Installation with pip requires the installation of systemd headers first. This means that a simple pip install maestral will no longer be possible.

[peterhoeg]

systemd v232 and above sets an $INVOCATION_ID environment variable Perfect, that simplifies things. I see no direct conflict with the GUI's autostart function, it could either continue as is or use systemd on Linux.

I might be going off on a tangent here, but one thing that could be interesting to explore is dbus activation: 1. you pick a name to take on dbus 2. dbus will be told to activate the backend service via systemd 3. when launching the GUI, it connects to the reserved name on dbus and if the backend isn't running, systemd will spawn it The problem with something like this is that it will no work with the pip install option as it will have to write to privileged locations in order to register which of course isn't a problem when packaged for a particular distribution.

In that system, "Up to date" is indeed a logging message of level INFO.

I'm fully with you here - the point is just that if there is another way to communicate status, you will not need to write that particular message to the log. In any case it's a minor detail.

This means that a simple pip install maestral will no longer be possible.

Currently, in order to use keyring against kwallet (KDE), you need dbus-python which also requires compilation. I understand that from an ease of adoption point of view, it's great when 'pip install' does the trick though.

[peterhoeg]

Turns out there are a few of the python modules that require compilation: ``` $ for d in $(nix-store --query -R /nix/store/v37a3s9x86fy9m7zp0rpipz7jsy4nhi4-maestral-0.3.2 | grep python3.7- ); do find $d -name '*.so' ; done /nix/store/a2pji6n8vwcql5rdkawvkda4zbn52skr-python3.7-cryptography-2.7/lib/python3.7/site-packages/cryptography/hazmat/bindings/_constant_time.abi3.so /nix/store/a2pji6n8vwcql5rdkawvkda4zbn52skr-python3.7-cryptography-2.7/lib/python3.7/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so /nix/store/a2pji6n8vwcql5rdkawvkda4zbn52skr-python3.7-cryptography-2.7/lib/python3.7/site-packages/cryptography/hazmat/bindings/_padding.abi3.so /nix/store/7z4rn3l8ai6bcmdw810k8j42pmskpq1h-python3.7-cffi-1.12.3/lib/python3.7/site-packages/_cffi_backend.cpython-37m-x86_64-linux-gnu.so /nix/store/r8rydg7gg9k3vh61241iw62kpv07rh38-python3.7-tornado-5.1/lib/python3.7/site-packages/tornado/speedups.cpython-37m-x86_64-linux-gnu.so /nix/store/b2cp5qzhmj0r64ifyv1gnr7s5zdd4glh-python3.7-pygobject-3.32.1/lib/python3.7/site-packages/gi/_gi.cpython-37m-x86_64-linux-gnu.so /nix/store/b2cp5qzhmj0r64ifyv1gnr7s5zdd4glh-python3.7-pygobject-3.32.1/lib/python3.7/site-packages/gi/_gi_cairo.cpython-37m-x86_64-linux-gnu.so /nix/store/dgl9wzmb1l9awfa63fkbnyy7d2bsjjcs-python3.7-pycairo-1.18.1/lib/python3.7/site-packages/cairo/_cairo.cpython-37m-x86_64-linux-gnu.so /nix/store/6bha1vdhmrqgkhkf1ad1734dnn9zvzbj-python3.7-dbus-python-1.2.4/lib/python3.7/site-packages/_dbus_bindings.so /nix/store/6bha1vdhmrqgkhkf1ad1734dnn9zvzbj-python3.7-dbus-python-1.2.4/lib/python3.7/site-packages/_dbus_glib_bindings.so /nix/store/nwnl6klcfa4f417yfyw4cqzd0iphnizp-python3.7-PyYAML-5.1.1/lib/python3.7/site-packages/_yaml.cpython-37m-x86_64-linux-gnu.so ```

[samschott]

Turns out there are a few of the python modules that require compilation

There is. I take back what I said, python-systemd seems to compile just fine when during a pip-install. It seems that most Linux distributions already come with the required packages for a compilation. In this case, I am happy to use it.

I might be going off on a tangent here, but one thing that could be interesting to explore is dbus activation

The current implementation (develop branch) does something very similar but uses Pyro4. On startup, the daemon will write a file with its pid and socket. This is used by the GUI or CLI to find the process and, in case of the GUI, to attach to a running daemon or otherwise create a new one. When the daemon is shut-down or crashes, the pid-file will be deleted again.

I am reluctant to use dbus because it is not installed on macOS by default (but can be installed via homebrew).

[samschott]

Small side-note: Maestral already uses launchd on macOS to auto-start on login, which is the equivalent to systemd. But it has the advantage that login-items registered with launchd will show up in the user's "System Preferences". Whereas GNOME does not seem to list systemd login-items under "Startup Applications" in the GUI, only ".desktop" entries in "~/.config/autostart".

[peterhoeg]

In this case, I am happy to use it.

👍

The current implementation (develop branch) does something very similar but uses Pyro4. On startup, the daemon will write a file with its pid and socket. This is used by the GUI or CLI to find the process and, in case of

Even better - then we can use socket activation which also works with launchd. You register the socket with systemd/launchd, and only upon connection by the CLI/GUI client is the backend spawned.

the GUI, to attach to a running daemon or otherwise create a new one. When the daemon is shut-down or crashes, the pid-file will be deleted again.

Ideally on linux that would be under $XDG_RUNTIME_DIR/maestral as that directory can then be set up and destroyed by systemd. Pretty much all linux distros these days will have XDG_RUNTIME_DIR set up.

I am reluctant to use dbus because it is not installed on macOS by default (but can be installed via homebrew).

Makes sense.

[peterhoeg]

login-items registered with launchd will show up in the user's "System Preferences".

I *believe* that both GNOME and KDE are moving towards using systemd units for spawning many of the user services, so I'm guessing that's just a matter of time before those can be managed in the UI as well.

[samschott]

Right, I have implemented using the journal when started from systemd, and sending status updates when running as a service with "Type=notify". You can try it out from the develop branch if you like.

For now, I will not rely on systemd/launchd to launch the daemon for the gui. While macOS is guaranteed to have launchd available, too many Linux systems which have Maestral installed do not use systemd (for instance CentOS 6).

[peterhoeg]

0.4.0 is very nice. I suggest we close this.