Marty Oehme
51178df4a3
Both greenclip and redshift did not automatically start on system start, since they needed X to be running but their restart was almost instantaneously. So, they restarted their alloted 5 times before X was ready and gave up. Restart time has been set to 5 and 10 seconds, so their startup takes a little longer but should, in most cases, succeed. |
||
|---|---|---|
| .. | ||
| .config/systemd/user | ||
| .local/share/services | ||
| README.md | ||
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 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.
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.