user service for mbsync: questions and improvements

[dkwo]

I wrote a dinit user service for mbsync (it uses pass and gnupg to check for mail).
Dinit is started as my user by turnstile, in void linux (with self-built 0.18).
This seems to work, but I wanted to ask for feedback, plus a bunch of related questions.

My attempt:

$ cat .config/dinit.d/mbsync 
type = process
load-options = export-passwd-vars
env-file = env-var-xdg
command = /usr/bin/snooze -H* -M 5/10 /bin/sh -c "/usr/bin/mbsync -a -c ${XDG_CONFIG_HOME}/mbsync/.mbsyncrc && /usr/bin/notmuch new"
log-type = file
logfile = /tmp/mbsync-dinit

with the variables

$ cat .config/dinit.d/env-var-xdg 
XDG_CONFIG_HOME=/home/dkwo/.config
XDG_DATA_HOME=/home/dkwo/.local/share
PASSWORD_STORE_DIR=/home/dkwo/.local/share/pass

Does this make sense in dinit?

Here's a bunch of things I don't understand:

• the service floods the system log of entries such as

 turnstiled: [  OK  ] mbsync
 turnstiled: [STOPPD] mbsync
 turnstiled: [  OK  ] mbsync

Is there a way to not have these? e.g. tweak scripted, restart or similar?

• in runit, I'd do exec 2>&1 before execing the command: is there a similar option in dinit?

• the substitution for $HOME does not work in the env-file, i.e. XDG_CONFIG_HOME=${HOME}/.config etc do not work. How to fix this?

• dinitctl signal does not have ALRM signal (in runit: sv alarm mbsync): would it make sense to add it? This is useful in conjunction with snooze.

Thanks.

[davmac314]

Does this make sense in dinit?

I think so, yes. If I understand correctly, you're wanting to run mbsync every 10 minutes. Dinit doesn't yet have any support for timers as yet so using something like snooze is a perfectly good way to achieve this. The service settings look reasonable to me.

the service floods the system log of entries such as

By default dinit outputs service state changes and it looks like these are then logged by turnstile. I haven't been using turnstile myself but AFAIU it uses a shell script to launch dinit. In that script, you could add the -q option to the dinit command line to suppress the service state change messages. This will apply to all services, there's currently no way to suppress messages for individual services.

in runit, I'd do exec 2>&1 before execing the command: is there a similar option in dinit?

That is the standard behaviour in dinit. (It won't suppress the state change messages however as those are issued by dinit itself, use -q for that as per above).

the substitution for $HOME does not work in the env-file, i.e. XDG_CONFIG_HOME=${HOME}/.config etc do not work. How to fix this?

There's no support for value substitution within in the env-file. Ideally it should be arranged (by turnstile/your pam configuration) that these particular variables (XDG_...) are set when dinit runs and then they will be inherited by all services, and you wouldn't need to use an env-file setting at all.

dinitctl signal does not have ALRM signal (in runit: sv alarm mbsync): would it make sense to add it?

I'd have no objection to adding it (feel free to open a PR).

You can also send signals via number - SIGALARM is signal 14 on Linux, according to man 7 signal.

[dkwo]

Thanks a lot for the clarifications, and for dinit!
I will try to understand better the turnstile side then for exporting variables.
The signal with number is already good for me, but I can make a PR at some point.

One last thing: I noticed this is logged when dinit starts (same config as above):
daemon.notice: Apr 11 10:26:38 turnstiled: dinit: In multiple cgroups, cannot determine cgroup root path
Is this something that I should be concerned about?

[mobin-2008]

Thanks a lot for the clarifications, and for dinit!
I will try to understand better the turnstile side then for exporting variables.
The signal with number is already good for me, but I can make a PR at some point.

One last thing: I noticed this is logged when dinit starts (same config as above):
daemon.notice: Apr 11 10:26:38 turnstiled: dinit: In multiple cgroups, cannot determine cgroup root path
Is this something that I should be concerned about?

No, because you probably don't use cgroups.