emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#26716: closed (Test nginx configuration)


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#26716: closed (Test nginx configuration)
Date: Thu, 11 May 2017 15:54:02 +0000

Your message dated Thu, 11 May 2017 17:53:46 +0200
with message-id <address@hidden>
and subject line Re: bug#26716: Test nginx configuration
has caused the debbugs.gnu.org bug report #26716,
regarding Test nginx configuration
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
26716: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=26716
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: Test nginx configuration Date: Sun, 30 Apr 2017 12:04:53 +0200
Hi, here are two patches to react to Christopher's experience. I added
two simple tests that check the presence of the certificate and the key
passed to nginx configuration.

If the error log file cannot be created at startup, error messages
about the configuration file are logged only on stderr. The second
patch makes sure the log file can be created.

Attachment: 0001-gnu-services-nginx-Test-certificate-presence.patch
Description: Text Data

Attachment: 0002-gnu-services-Create-logs-directory.patch
Description: Text Data


--- End Message ---
--- Begin Message --- Subject: Re: bug#26716: Test nginx configuration Date: Thu, 11 May 2017 17:53:46 +0200 User-agent: mu4e 0.9.18; emacs 25.2.1
Christopher Allan Webber <address@hidden> writes:

> Julien Lepiller writes:
>
>>> So is the goal here that it will raise an exception if it doesn't
>>> exist, like so?
>>> 
>>>   ERROR: In procedure lstat: No such file or directory:
>>> "/tmp/no-such-file"
>>> 
>>> That does seem like useful information to spit out.
>>> 
>>> Maybe add a comment before the lstat explaining the call?  If I didn't
>>> know that's why lstat was being used here I would have been confused.
>> exactly, I added a comment.
>
> Great!
>
>>> Oh, that's interesting.  So in my experience earlier, it was proably
>>> *trying* to log some information, and failing I guess.
>>> 
>>> It would be even nicer if they wrote to the same file by default, but
>>> I guess this probably isn't easy to do without actually patching nginx
>>> itself, which isn't likely worth it... is that right?
>> I tried using the -g option to give it some configuration options
>> (including error_log), but it doesn't seem to change that behaviour, so
>> I think we'll have to fix nginx to use the same configuration file.
>>
>> Of course it would be better to fail at reconfigure when the generated
>> configuration is not correct. That's what I'm trying to do with the
>> first patch, but that's only one possible mistake.
>
> Cool... yes I agree it's only one possible mistake. :)
>
> Looks good.  I assume you've tried testing building with it?  Assuming
> all builds and things also error out right now in the new and expected
> ways when the configuration needs updating, I say push it!

Closing it as it has been pushed.  Thanks!


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]