<h1 id="title">Emacs daemon as a runit "user service"</h1>
<div id="dates">
<span>Posted: <time id="post-date">2020-07-30</time></span>
</div>
<p id="post-excerpt">
A while back, <a href="/blog/emacs-daemon-runit-service/">I wrote about</a> setting up a runit service for an Emacs daemon. The idea behind that post was that you'd have a system-level service for your user Emacs session. But what if you want a "user service", like what systemd-using folks have? Read on to find out how to replicate this with runit!
</p>
<div id="toc"></div>
<h3>What Is A User Service?</h3>
<p>
First off, what even is a user service? As a reference, see <a href="https://emacsredux.com/blog/2020/07/16/running-emacs-with-systemd/">this piece by Bozhidar Batsov</a> about running Emacs with systemd's version of user services. With runit, it's simply a <code>runsvdir</code> that your user can write to. <span class="footnote"> <a href="http://smarden.org/runit/runsvdir.8.html">runsvdir - starts and monitors a collection of runsv(8) processes</a></span> <span class="footnote"> <a href="http://smarden.org/runit/faq.html#userservices">Does runit support user-specific services?</a></span>
</p>
<h3>Your User's Runsvdir</h3>
<p>
Before you can have a user service for your Emacs daemon, you've got to have a service for your user services! This is because runit has no specific notion of user versus system services. So if you want a user to be able to easily manage some services, simply give them their own <code>runsvdir</code>.
</p>
<p>
The <code>/etc/sv/hristos-runsvdir/run</code> file for that looks like this:
</p>
<pre><code class="language-sh">#!/bin/sh
user=hristos
exec 2>&1
exec chpst -u $user runsvdir /home/$user/.local/sv</code></pre>
<p>
Enable that, and now your user can write to <code>$HOME/.local/sv</code> as a service directory. It's also possible to enable logging for this or any child services, if desired.
</p>
<h3>The Emacs Daemon User Service</h3>
<p>
The "user service" file (<code>/home/hristos/.local/sv/emacs-daemon/run</code>) doesn't look much different than the system-wide version:
</p>
<pre><code class="language-sh">#!/bin/sh
export USER=hristos
export HOME=/home/$USER
export PATH=$HOME/.local/bin:$PATH
# .. any other variables you need can go here ..
cd $HOME
exec /usr/bin/emacs --fg-daemon=$USER-emacsd</code></pre>
<p>
The most noteable change here is that the command no longer uses <code>chpst</code> to run as a certain user, and the trailing output redirection (<code>2>&1</code>) is also omitted due to that being handled by the parent "user service" service as described above.
</p>
<h3>Functions/Shortcuts</h3>
<p>
As before, I'm using some fish functions to simplify interracting with services:
</p>
<pre><code class="language-fish"># A shortcut function for interacting with user services:
function usv
env SVDIR=$HOME/.local/sv sv $argv
end
# A shortcut function for launching an Emacs client process that connects to my daemon:
function emacs
command emacsclient --socket-name=hristos-emacsd -c -n $argv ; or \
zenity --error --no-wrap --text 'Failed to connect to the Emacs daemon!' ^/dev/null
end</code></pre>
<p>
I call that <code>emacs</code> function externally like this: <code>fish -c "emacs"</code>.
</p>
<h3>Sudo Rules?</h3>
<p>
The method described above, utilizing "user services", is a bit better because it doesn't require any kind of privilege escalation outside of enabling the initial <code>runsvdir</code>. But can you use a system-level service without such escalation?
</p>
<p>
It turns out it is indeed also possible to have an Emacs daemon at the system-level but not require <code>sudo</code> or other privilege elevation methods. That's definitely worth checking out if a "user service" isn't something you need. <span class="footnote"> <a href="http://smarden.org/runit/faq.html#user">Is it possible to allow a user other than root to control a service</a></span>
</p>
<h3>Conclusion</h3>
<p>
There you have it, "user services" for runit and an Emacs daemon service for it. Is it one-to-one, the same as in systemd-land? No, but it is close enough where it matters and allows quite a bit of flexibility. Happy daemon-ing!
</p>
<h3>Footnotes And References</h3>
<div id="footnotes"></div>