all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Cameron <cam@tindall.space>
To: "Efraim Flashner" <efraim@flashner.co.il>
Cc: "julia.galaman--- via" <help-guix@gnu.org>
Subject: Re: Custom Service Definition for Caddy
Date: Mon, 01 Feb 2021 08:46:03 -0600	[thread overview]
Message-ID: <7c9d921d-b939-413b-aeef-692b527f93b0@www.fastmail.com> (raw)
In-Reply-To: <YBL/o9V8Gx14u04H@3900XT>

Thanks Efraim! I actually spent some time last night with strace trying to figure out if the thing forks or not. "caddy run" is *supposed& to not daemonize, but who knows if it does some other fork funny business. It was late though and I couldn't keep my eyes open.

In the cold light of day this morning, I realized that Caddy 2.3.0 adds a '-pidfile' option that lets you set a pidfile. With that, I can easily satisfy 'make-forkexec-contstructor' because it has the #:pid-file option to get the pid of the running daemon from there instead. I ended up with this package and service definition, which work beautifully:

#+begin_src 
(define caddy
  (package
   (name "caddy")
   
   (version "2.3.0")
   
   (source
    (origin
     (method url-fetch/tarbomb)
     (uri (string-append "https://github.com/caddyserver/caddy/releases/download/v" version "/caddy_" version "_linux_amd64.tar.gz"))
     (sha256
      (base32
       "0jfh5bxg36l4jrdd7y240irykrdvxi3d4hwq0bm2b8hki573fy8m"))))

   (build-system copy-build-system)

   (arguments
    '(#:install-plan '(("caddy" "bin/caddy"))))
   
   (synopsis "This is a *BAD* Caddy package. It just pulls the already-built binary from Github, rather than building from source.")
   (description "See https://caddyserver.com/")
   (home-page "https://caddyserver.com/")
   (license licenses:asl2.0)))

(define-record-type* <caddy-configuration>
  caddy-configuration  make-caddy-configuration caddy-configuration?)

(define caddy-service-type
  (shepherd-service-type
   'caddy
   (lambda (config)
     (shepherd-service
      (documentation "Run the caddy daemon (caddy).")
      (provision '(caddy))
      (requirement '(user-processes))
      (start #~(make-forkexec-constructor '("caddy" "start"
					    "-config"  "/etc/Caddyfile"
				            "-pidfile" "/var/run/caddy.pid")
					  #:pid-file "/var/run/caddy.pid"))
      (stop #~(make-kill-destructor))))))
#+end_src


-Cam


On Thu, Jan 28, 2021, at 12:17 PM, Efraim Flashner wrote:
> On Tue, Jan 26, 2021 at 11:02:58AM -0600, Cameron wrote:
> > Hello again everyone!
> > 
> > I'm having a great time learning about Guix, but am struggling with defining a custom service for Caddy. The 'caddy' package below works as expected -- installing it puts the "caddy" binary in $PATH and it works fine when I run it from a shell.
> > 
> > 
> > #+begin_src 
> <code snipped>
> > #+end_src
> > 
> > What doesn't work as expected is this service definition:
> > 
> > #+begin_src 
> > (define-record-type* <caddy-configuration>
> >   caddy-configuration  make-caddy-configuration caddy-configuration?
> >   (config-file          caddy-configuration-config-file
> >                         (default "/etc/Caddyfile")))
> > 
> > (define caddy-service-type
> >   (shepherd-service-type
> >    'caddy
> >    (lambda (config)
> >      (shepherd-service
> >       (documentation "Run the caddy daemon (caddy).")
> >       (provision '(caddy))
> >       (requirement '(user-processes))
> >       (start #~(make-forkexec-constructor
> > 			     (list "caddy" "run"
> > 				   "-config" "/etc/Caddyfile")
> > 				   #:log-file "/var/log/caddy.log"))
> >       (stop #~(make-kill-destructor))))))
> > #+end_src
> > 
> > ...which I then add to my services list in config.scm like this:
> > 
> > #+begin_src 
> > 			 (service caddy-service-type
> > 				  (caddy-configuration
> > 				   (config-file "/etc/Caddyfile")))
> > #+end_src
> > 
> > With this setup, 'herd start caddy' hangs for 30 seconds, during which time the server is active and taking traffic according to the config in /etc/Caddyfile but then something (presumably Shepherd) sends it a SIGTERM and it dutifully shuts down. The 'herd start caddy' then exits with an error:
> > 
> > #+begin_src 
> > root@tindall ~# START=$(date +%s); herd start caddy; END=$(date +%s); echo $(($END - START))
> > Service caddy could not be started.
> > herd: failed to start service caddy
> > 30
> > root@tindall ~# tail -n 1 /var/log/caddy.log 
> > {"level":"info","ts":1611680035.1811087,"msg":"shutdown done","signal":"SIGTERM"}
> > root@tindall ~# 
> > #+end_src
> > 
> > 'caddy run' will keep caddy in the foreground, but I see the same behavior when I use 'caddy start' (which forks another process for the daemon and exits immediately) in the service definition instead.
> > 
> > I suspect something is wrong with the 'start' procedure I've defined, but I'm struggling to figure out what it is.
> > 
> > What am I missing?
> > 
> > -Cameron
> > 
> 
> Does caddy fork when you run "caddy run?" 'make-fork-constructor' forks
> when it runs the code, so if caddy also forks then you have a
> double-forked codepath and shepherd thinks the process is gone, so it
> goes to kill it. If caddy doesn't have something like --foreground or
> --no-daemonize then you might be looking at something like exec-command
> from the manual¹.
> 
> Alternatively it might work if you can set a PID file.
> 
> ¹ 
> https://www.gnu.org/software/shepherd/manual/html_node/Service-De_002d-and-Constructors.html#Service-De_002d-and-Constructors
> 
> -- 
> Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
> GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
> Confidentiality cannot be guaranteed on emails sent or received unencrypted
> 
> Attachments:
> * signature.asc


      reply	other threads:[~2021-02-01 14:47 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-26 17:02 Custom Service Definition for Caddy Cameron
2021-01-28 18:17 ` Efraim Flashner
2021-02-01 14:46   ` Cameron [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7c9d921d-b939-413b-aeef-692b527f93b0@www.fastmail.com \
    --to=cam@tindall.space \
    --cc=efraim@flashner.co.il \
    --cc=help-guix@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.