Bugzilla – Full Text Bug Listing
| Summary: | signing process needs better logging | ||
|---|---|---|---|
| Product: | Community | Reporter: | Kim Moir <kim.moir> |
| Component: | Servers | Assignee: | Eclipse Webmaster <webmaster> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | christian.campo, david_williams |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Kim Moir
(In reply to comment #0) > It would be nice if there was a log for each signing process that is invoked. Since many signing processes can run simultaneously, here's what I suggest: - we keep everything in a single log file - we rotate log file every night - we don't truncate the logfile at the beginning of a job, like we do now - since every job is based on a queue, we prefix messages in the log with the queue id (ie, pid) _where we can_. Here is an example. This is based loosely on a Postfix-style mail log: 2010-04-27 13:35:01 QUEUE: Begin processing queue: 23175 1272389645:droy:/home/data/httpd/download-staging.priv/technology/phoenix/org.eclipse.sdk_3.0.1.jar:mail:/home/data/httpd/download-staging.priv/technology/phoenix ======================= end of (23175) contents 2010-04-27 13:35:01: QUEUE(23175): calling jarprocessor.jar for /home/data/httpd/download-staging.priv/technology/phoenix/org.eclipse.sdk_3.0.1.jar 2010-04-27 13:35:05 SIGNER(23175): asked to sign /opt/public/download-staging.priv/technology/phoenix/org.eclipse.sdk_3.0.1.jar 2010-04-27 13:35:05 SIGNER(23175): Finished signing /opt/public/download-staging.priv/technology/phoenix/org.eclipse.sdk_3.0.1.jar 2010-04-27 13:35:01: QUEUE(23175): Finished processing queue. Of course, the above log messages could contain messages from another queue should there be two (or more) queues running. But, like a mail log, you should be able to easily trace what is going on. You can tail this right now, on build: /tmp/signing/signer.log. Sounds adequate to me ... little that I know. One question though, we sometimes like to "snag" a copy of logs (such as this one) and keep with the build results for later checking/confirmation/records ... how large would this file get? Large enough to prohibit copying every build? Mostly just curious. Even if possible, not sure we would do this, unless becomes a frequent problem. Thanks, Thanks Denis for setting this up. I think you need to adjust the permissions on the log kmoir@build:~> tail -f /tmp/signing/signer.log tail: cannot open `/tmp/signing/signer.log' for reading: Permission denied tail: no files remaining I knew that. Just checking if you were paying attention. I'm always paying attention :-) > how large would this file get?
It's currently sitting at 13M uncompressed. It likely contains a lot of irrelevant chit-chat from other signing requests.
Kim, does the current log format/method work for you? I haven't added it to our nightly logrotate script yet, so you'll see more than 24h worth of activity. Yes it looks good to me. Thanks! Closing as fixed. as a side-note.....maybe it would be a good idea to fix the signing script since it still suggest to tail - f /tmp/jarsigner when "sign xxx mail ./out" is started. Now that obviously that location has changed to tail -f /tmp/signing/signer.log. |