41 lines
3 KiB
Markdown
41 lines
3 KiB
Markdown
|
# User services
|
||
|
|
|
||
|
|
This module uses `systemd` to provide various services for the user running the dotfiles.
|
||
|
|
The services will get moved into the correct `.config` directory for `systemd` to pick them up as user services.
|
||
|
|
|
||
|
|
They will, for now, *not* be automatically enabled when installing the dotfiles. This is pending changes.
|
||
|
|
They can be enabled as needed by invoking `systemctl --user enable [service]`. Be aware that
|
||
|
|
|
||
|
|
## Why systemd
|
||
|
|
|
||
|
|
There are two reasons for the service module making use of `systemd` to manage its services:
|
||
|
|
|
||
|
|
The machine(s) these dotfiles are currently targeting are both archlinux-based.
|
||
|
|
That means, pragmatically, I will adhere to using `systemd` since it is what arch uses as init manager.
|
||
|
|
I *am* eye-ing alternatives like [Artix Linux](https://artixlinux.org/) but adopting it is, if it happens at all, still a way out due to my current time constraints.
|
||
|
|
|
||
|
|
Secondly, I am using this opportunity to learn more about `systemd`.
|
||
|
|
There are various arcane-seeming invocations in `systemd` which are beginning to make more sense to me as time goes on
|
||
|
|
(looking at you, `journalctl`).
|
||
|
|
I do not want to dismiss a program without having given it a fair shake (especially if it enjoys *such* widespread adoption).
|
||
|
|
Additionally, process watching and automatic maintenance, as well as the entire `.timer` system that it can provide for services are pretty fantastic, even if their syntax takes some getting used to for me.
|
||
|
|
|
||
|
|
That said, there are also many moments where I am envious of the simplicity and straightforward nature of something like [runit](http://smarden.org/runit/).
|
||
|
|
So what that essentially means: this service module uses `systemd` *for now*.
|
||
|
|
It might change to something else in the future.
|
||
|
|
It might also not be written very well, since I am using it to adopt a mental mapping of `systemd` at the same time.
|
||
|
|
|
||
|
|
## Commit Notes service
|
||
|
|
|
||
|
|
This service keeps my university note directory in sync with a remote origin.
|
||
|
|
The script behind it (`git-sync`) can be used more generally to keep any git directory in sync.
|
||
|
|
|
||
|
|
The idea behind the services is: commit asap, push when finished.
|
||
|
|
It basically runs on two different timers, every x seconds (120 by default, can be changed with `GS_TIME_TO_COMMIT` env var) it will commit whatever changes took place in the directory.
|
||
|
|
After x runs of the commit timer *without changes* (30 by default, can be changed with `GS_UNCHANGED_RUNS_TO_PUSH`) it will push the git index to its default remote.
|
||
|
|
|
||
|
|
In effect this means, using the default values, the service will commit any changes made every two minutes and when *no* changes were made for an hour (±2minutes), it will push it to remote.
|
||
|
|
|
||
|
|
The two cycles can be changed independently from each other via the environment variables mentioned above so that, for example, the repository can be pushed every single time a commit takes place, or commits can be checked for on faster or shorter intervals.
|
||
|
|
As another example, if you want to check for changes every 30 seconds but still push every hour, you would do `GS_TIME_TO_COMMIT=30` and `GS_UNCHANGED_RUNS_TO_PUSH=120`.
|