* Custom Service Definition for Caddy
@ 2021-01-26 17:02 Cameron
2021-01-28 18:17 ` Efraim Flashner
0 siblings, 1 reply; 3+ messages in thread
From: Cameron @ 2021-01-26 17:02 UTC (permalink / raw)
To: help-guix
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
(define caddy
(package
(name "caddy")
(version "2.2.1")
(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
"1va2h8hpxcby9rny7px1y2xks79rxb4svnf9mrdrlc5xn0s04dsx"))))
(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)))
#+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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Custom Service Definition for Caddy
2021-01-26 17:02 Custom Service Definition for Caddy Cameron
@ 2021-01-28 18:17 ` Efraim Flashner
2021-02-01 14:46 ` Cameron
0 siblings, 1 reply; 3+ messages in thread
From: Efraim Flashner @ 2021-01-28 18:17 UTC (permalink / raw)
To: Cameron; +Cc: help-guix
[-- Attachment #1: Type: text/plain, Size: 3210 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Custom Service Definition for Caddy
2021-01-28 18:17 ` Efraim Flashner
@ 2021-02-01 14:46 ` Cameron
0 siblings, 0 replies; 3+ messages in thread
From: Cameron @ 2021-02-01 14:46 UTC (permalink / raw)
To: Efraim Flashner; +Cc: julia.galaman--- via
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-02-01 14:47 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-01-26 17:02 Custom Service Definition for Caddy Cameron
2021-01-28 18:17 ` Efraim Flashner
2021-02-01 14:46 ` Cameron
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.