[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#29466] [PATCH] services: web: Add support for configuring the nginx
[bug#29466] [PATCH] services: web: Add support for configuring the nginx server names hash.
Sun, 10 Dec 2017 09:00:28 +0000
mu4e 0.9.18; emacs 25.3.1
Ludovic Courtès writes:
>> The nginx service can fail to start if the server names hash bucket size is
>> too small, which can happen on some systems, and when using QEMU, depending
>> the CPU.
>> * gnu/services/web.scm (<nginx-configuration>): Add
>> server-names-hash-bucket-size and server-names-hash-bucket-max-size.
>> (default-nginx-config): Add support for the new hash bucket size
>> (nginx-service, nginx-activation): Pass the new hash bucket size parameters
>> through to the default-nginx-config procedure.
>> * doc/guix.texi (Web Services): Document the new hash bucket size parameters.
>> -(define (default-nginx-config nginx log-directory run-directory server-list
>> +(define (default-nginx-config nginx log-directory run-directory server-list
>> + upstream-list server-names-hash-bucket-size
>> + server-names-hash-bucket-max-size)
> That’s too many positional parameters. And should we use a gexp
> compiler for <nginx-configuration> anyway?
>> (define nginx-shepherd-service
>> (($ <nginx-configuration> nginx log-directory run-directory
>> - upstream-blocks file)
>> + upstream-blocks server-names-hash-bucket-size
>> + server-names-hash-bucket-max-size file)
> Likewise, at this stage, we should probably use ‘match-record’ to avoid
I've sent a couple of additional patches now, the first makes the change
to using match-record, and the second splits out the configuration file
part of the <nginx-configuration> record, and adds a gexp compiler for
Let me know what you think about the 2nd patch? I don't particularly
like the duplication between the two records, as both the
<nginx-configuration> and <nginx-config-file> records need the package,
log directory and run directory for different reasons.
nginx: used for the nginx binary in the shepherd service
log-directory: created in the activation service
run-directory: created in the activation service
nginx: used for the mime.types file
log-directory: written in to the config file
run-directory: written in to the config file
It's important that it's possible to specify the log directory and run
directory if you don't use the <nginx-config-file>, and instead use
something opaque (like a <local-file>). But I dislike the duplication
that this is adding.
I wonder if there is a better way of supporting the use of a raw
configuration file, rather than the record. Possibly by providing an
easy way to create a custom nginx-service-type, with a different
activation phase? I think that would allow for making the original
<nginx-configuration> compile to the configuration file, but then have
something like this for a custom config file.
One downside with this approach is that service extensions use the
service-type, so modifying it would mean that services that extend nginx
wouldn't work with this service type (you'd have to have the original as
well, or modify the service with the extension).
In the 2nd patch, I put in some (bad) handling of the extension case, as
with an opaque config file, you can't do anything. Previously, the
configuration was changed, but then this is later ignored, as the file
Thanks for reviewing,
Description: PGP signature
|[Prev in Thread]
||[Next in Thread]|
- [bug#29466] [PATCH] services: web: Add support for configuring the nginx server names hash.,
Christopher Baines <=