From mboxrd@z Thu Jan 1 00:00:00 1970 From: Danny Milosavljevic Subject: Re: Defining user services in Guix. Date: Sat, 22 Apr 2017 20:31:31 +0200 Message-ID: <20170422203131.610f2a30@scratchpost.org> References: <87o9vowfn0.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:40710) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d1zot-0003EP-Fy for guix-devel@gnu.org; Sat, 22 Apr 2017 14:31:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d1zoq-0004NX-B1 for guix-devel@gnu.org; Sat, 22 Apr 2017 14:31:43 -0400 Received: from dd1012.kasserver.com ([85.13.128.8]:42106) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1d1zoq-0004MV-4I for guix-devel@gnu.org; Sat, 22 Apr 2017 14:31:40 -0400 In-Reply-To: <87o9vowfn0.fsf@gmail.com> 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: Mathieu Othacehe Cc: guix-devel@gnu.org Hi Mathieu, personally, I'd just start it inside ~/.xinitrc, ~/.xsession, ~/.fluxbox/startup or similar. That's a little old-school, though, but it's how I always did those things. The disadvantage is that if redshift crashes, it's not being brought back up. But you can start your own shepherd under your user account and have that shepherd manage user services - it's nice. Create a file ${XDG_CONFIG_HOME-.config}/shepherd/init.scm and put your services there: (use-modules (shepherd service)) (define redshift (make #:provides '(redshift) #:start ...)) (register-services redshift) ; Note: if there has already been a (register-services) form, replace it You can then launch your own shepherd: mathieu@xxx $ shepherd And manage it using herd: mathieu@xxx $ herd start redshift You can also load files at runtime using: $ herd load shepherd ~/bla.scm See also $ info shepherd Unfortunately, it still doesn't respawn redshift if it dies - it seems to require a pid file for that (#:start (make-forkexec-constructor ... #:pid-file "xxx.pid") and you have to specify #:respawn? #t. The invoked program then has to create "xxx.pid"). I think it would be a nice addition to have it monitor the process that make-forkexec-constructor invoked - without any pid file. Maybe it's even a bug... To reproduce: dannym@dayas ~/.config/shepherd$ cat init.scm (use-modules (shepherd service)) (define redshift (make #:provides '(redshift) #:start (make-forkexec-constructor '("/run/current-system/profile/bin/xterm") ; to make it more obvious ) #:stop (make-kill-destructor) #:respawn? #t)) (register-services redshift) ;; Services known to shepherd: ;; Add new services (defined using 'make ') to shepherd here by ;; providing them as arguments to 'register-services'. ;(register-services) ;; Send shepherd into the background (action 'shepherd 'daemonize) ;; Services to start when shepherd starts: ;; Add the name of each service that should be started to the list ;; below passed to 'for-each'. (for-each start '()) dannym@dayas ~/.config/shepherd$ shepherd dannym@dayas ~/.config/shepherd$ herd start redshift At first I thought that was because a regular exit is not bad - so I did instead: dannym@dayas ~/.config/shepherd$ herd start redshift dannym@dayas ~/.config/shepherd$ herd status redshift dannym@dayas ~/.config/shepherd$ kill -9 On the plus side, you have access to the correct DISPLAY and XAUTHORITY just fine there.