Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No way to differenciate log entries for test runs #1339

Closed
AGlezB opened this issue Jan 7, 2020 · 2 comments
Closed

No way to differenciate log entries for test runs #1339

AGlezB opened this issue Jan 7, 2020 · 2 comments
Milestone

Comments

@AGlezB
Copy link

AGlezB commented Jan 7, 2020

Is your feature request related to a problem? Please describe.
As of version 2.1.2.641 there is no way to tell appart test and production runs in the log.

Test run:

2020-01-07 10:51:13.110 -03:00 [INF] Software version 2.1.2.641 (RELEASE, UNPLUGGABLE) started
2020-01-07 10:52:58.580 -03:00 [INF] Renewing certificate for [Manual] www.example.com
2020-01-07 10:53:39.221 -03:00 [INF] Next renewal scheduled at 2020-03-02 10:53:39
2020-01-07 10:53:39.236 -03:00 [INF] Renewal for [Manual] www.example.com succeeded

Production run:

2020-01-07 11:15:20.829 -03:00 [INF] Software version 2.1.2.641 (RELEASE, UNPLUGGABLE) started
2020-01-07 11:15:21.345 -03:00 [INF] Renewing certificate for [Manual] www.example.com
2020-01-07 11:16:03.704 -03:00 [INF] Next renewal scheduled at 2020-03-02 11:16:03
2020-01-07 11:16:03.736 -03:00 [INF] Renewal for [Manual] www.example.com succeeded

You can do a) a test run and a production run or b) just two test runs and both will log the same. If I look at the log and see Renewal for XXXXX succeeded I might assume that everything is fine without realizing that it only applies to the test environment.

Describe the solution you'd like
Log to different files ie. log-{date}.txt for prod and log-{date}-test.txt for testing (--test).

Describe alternatives you've considered
Any of:

  • Add an additional log line like:
2020-01-07 10:51:13.110 -03:00 [INF] Software version 2.1.2.641 (RELEASE, UNPLUGGABLE) started
2020-01-07 10:51:13.200 -03:00 [INF] Running in TEST mode
2020-01-07 10:52:58.580 -03:00 [INF] Renewing certificate for [Manual] www.example.com
  • Add a preffix to log lines for testing:
2020-01-07 10:51:13.110 -03:00 [INF] [TEST] Software version 2.1.2.641 (RELEASE, UNPLUGGABLE) started
2020-01-07 10:52:58.580 -03:00 [INF] [TEST] Renewing certificate for [Manual] www.example.com

Additional context
Also I don't know if win-acme supports running multiple instances concurrently but please log the process ID, just in case:

2020-01-07 10:51:13.110 -03:00 [PID-1234] [INF] Software version 2.1.2.641 (RELEASE, UNPLUGGABLE) started
2020-01-07 10:52:58.580 -03:00 [PID-1234] [INF] Renewing certificate for [Manual] www.example.com
@WouterTinus
Copy link
Member

I don't like the idea of doing anything special for --test, but I will make three small changes for the next release:

  • When using a custom logging folder, sub folders will be created for each ACME endpoint that you use. Note that this is different from seperating --test and regular runs, because you can do a --test run on a production ACME endpoint and likewise a regular run on an ACME staging endpoint.
  • At startup, the command line provided will be logged to disk.
  • The Process ID will be available as context for custom logging, and an example on how to set that up will be added to the documentation. Running multiple instances of the program with the same ACME endpoint is not supported, but currently nothing would stop you from doing that.

I hope this will help to address your concerns.

@WouterTinus WouterTinus added this to the 2.1.3 milestone Jan 9, 2020
@AGlezB
Copy link
Author

AGlezB commented Jan 9, 2020

When using a custom logging folder, sub folders will be created for each ACME endpoint that you use. Note that this is different from seperating --test and regular runs, because you can do a --test run on a production ACME endpoint and likewise a regular run on an ACME staging endpoint.

That it is way better. I wasn't thinking in terms of endpoints.

I hope this will help to address your concerns.

Sure does! Thanks. 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants