From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pierre Neidhardt Subject: Guix shepherd user services Date: Sun, 10 Feb 2019 16:02:05 +0100 Message-ID: <87bm3j4rgy.fsf@ambrevar.xyz> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([209.51.188.92]:55344) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gsqcW-0006A4-13 for guix-devel@gnu.org; Sun, 10 Feb 2019 10:02:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gsqcU-0008PW-R4 for guix-devel@gnu.org; Sun, 10 Feb 2019 10:02:11 -0500 Received: from relay6-d.mail.gandi.net ([217.70.183.198]:48255) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gsqcU-0008Ns-HY for guix-devel@gnu.org; Sun, 10 Feb 2019 10:02:10 -0500 List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Guix-devel Cc: alex.ter.weele@gmail.com, Ludovic =?utf-8?Q?Court=C3=A8s?= --=-=-= Content-Type: text/plain I've been thinking about shepherd user services. We just had a discussion on the topic: https://lists.gnu.org/archive/html/help-guix/2019-02/msg00010.html and an interesting patch was sent a while ago: https://lists.gnu.org/archive/html/guix-devel/2018-02/msg00047.html. Jelle first introduced me to this idea during the Guix days and it took me a while to understand why it's pure awesomeness. In short: just like we can fully configure an operating-system in Guile and we don't have to touch /etc manually, we could do the same with our user profile. At last, done with .bashrc / .profile to start user daemons, cron jobs, whatever synchronization script you use... It would also make it possible to fully _initialize_ a user profile (just like we initialize the operating-system) with the desired files. For instance, a service could synchronize git repositories (e.g. your dotfiles), deploy it, synchronize your emails, generate the mlocate cache, snapshot some btrfs drives, you name it. As a result, on a Guix install it would be possible to run guix service --install -f my-services.scm let the magic happen, relog(?) et enjoy a 100% pre-configured user profile. How cool is that? Benefits over traditional dotfiles or cron jobs: - No more need for .xinitrc, .local/bin, etc. - Declarative and uniformly programmable in Guile. - Every service is uniformly controllable (start, restart, stop, status, etc.). It's not so convenient to do that with a daemon that was started from .xinitrc. - Drags non-propagated inputs automatically, no need to polute the user profile (e.g. with redshift, xcape, etc.) - Pre-configured services to choose from, as provided by Guix (unlike mcron). My thoughts regarding the implementation design: - Services can be enabled, disabled, started, restarted, stopped, listed, they can show details and documentation, they can run pre-defined actions. They are semantically very different from packages (in fact they often use packages, but not always). I don't think it would be good to mix and match services and packages in a command like `guix package --list-installer`. So I suggest we keep them separate. - The user must be able to build and install services. We could have the following behaviour then: `guix service --build redshift` would produce a /gnu/store/...-shepherd-redshit.scm `guix service --install redshift` would install it to ~/.guix-profile/services/redshift.scm. `guix service --remove redshift` would remove it from the above location. `guix service --upgrade=redshift` would rebuilt the service (and maybe redshift) and install the new version. - How do we write custom services? Well, just like we write custom packages and custom operating-system, in a channel or in GUIX_PACKAGE_PATH (which name becomes less and less meaningful). - How do we update services (e.g. the redshift service when the redshift package just got updated)? My understanding is that services are citizens similar to operating system declarations: they depend on the current Guix version and the user-defined definitions (e.g. channels). Then `guix pull && guix service --upgrade` will do. - How do we start the user shepherd on login and load the service configuration? We need to be cautious to support foreign distributions. On GuixSD, we could arrange /etc/profile to run shepherd --config ~/.guix-profile/service-manifest.scm on login. On foreign distributions, users can add the above command to ~/.profile, or ~/.bashrc, etc. - If the package manifest and the service manifest are separate, it follows that we now have 2 parameters to "reproducibly" define a user profile. I think that's fine and it allows for composition (mix and match service manifests and package manifests). - Currently I think it's not possible to just define shepherd services without enabling them. Thus it's not possible to have a list of available services just like we have a list of packages. While this might be OK for the system (but is it?), I think it would be nice if, as a user, we could do a guix service --list-available and pick services from there. This is somewhat a separate issue but it would be nice to solve it. I don't know enough about the shepherd internals to go into the details here. - Should Guix drive the services with a `guix service` subcommand or should we leave it to `herd` run by the user? Since we use `herd` for system services, I think it's more consistent to stick to `herd`. I'd like to work on it with anyone interesting on the topic. I know some people I've worked on it before, so feel free to share your progress :) -- Pierre Neidhardt https://ambrevar.xyz/ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEUPM+LlsMPZAEJKvom9z0l6S7zH8FAlxgPO0ACgkQm9z0l6S7 zH+7fAf/YtHYU1a5mUkmSvqfcOVDcmRDWyxLx8BVw5z9UFgoGTNVWwIUw4yWkEMT Ijq2zuGLBd9kz0/M9+9s6ZoAWqGM3zmJQ5x8EgU0ZXh5AHH6s3eYdpYeCBssFoQM 5+9CfcHzVPJk/PAEW7JhIfoHdDJibQaiovZGOAeWZvzkzavUtSn3oXy1kKGzTDgR 8WMI4v+85WmtDK1M5biIqFUort3D55jkP3XfyZ5bKDYxZD/33HwYj2Y69MbCb9J/ js580xFReGUzeMfwnTPPKhRSZ2G7xSkrxo1ZX7d3HY+BjRpXoz07EUAquxwknt4d 0nbjt5JsL8NvpAaXpBDm2LLGaWc9Xw== =ozTN -----END PGP SIGNATURE----- --=-=-=--