Red Hat Bugzilla – Bug 1184591
Some Sat 6 reports show incorrect time as GMT
Last modified: 2016-07-27 04:46:39 EDT
Description of problem: Some reports in Satellite 6, such the runtime and resources reports under a host definition under Hosts -> All Hosts, show the time incorrectly as GMT. How do we configure this to show the correct current timezone? Version-Release number of selected component (if applicable): Installed Packages candlepin-0.9.23.1-1.el7.noarch candlepin-common-1.0.1-1.el7.noarch candlepin-guice-3.0-2_redhat_1.el7.noarch candlepin-scl-1-5.el7.noarch candlepin-scl-quartz-2.1.5-6.el7.noarch candlepin-scl-rhino-1.7R3-3.el7.noarch candlepin-scl-runtime-1-5.el7.noarch candlepin-selinux-0.9.23.1-1.el7.noarch candlepin-tomcat-0.9.23.1-1.el7.noarch elasticsearch-0.90.10-6.el7sat.noarch katello-1.5.0-30.el7sat.noarch katello-certs-tools-1.5.6-1.el7sat.noarch katello-default-ca-1.0-1.noarch katello-installer-0.0.64-1.el7sat.noarch katello-server-ca-1.0-1.noarch pulp-admin-client-2.4.3-1.el7sat.noarch pulp-katello-0.3-4.el7sat.noarch pulp-nodes-common-2.4.3-0.1.beta.el7sat.noarch pulp-nodes-parent-2.4.3-0.1.beta.el7sat.noarch pulp-puppet-plugins-2.4.3-1.el7sat.noarch pulp-puppet-tools-2.4.3-1.el7sat.noarch pulp-rpm-plugins-2.4.3-1.el7sat.noarch pulp-selinux-2.4.3-1.el7sat.noarch pulp-server-2.4.3-1.el7sat.noarch python-gofer-qpid-1.3.0-1.el7sat.noarch python-isodate-0.5.0-1.pulp.el7sat.noarch python-kombu-3.0.15-12.pulp.el7sat.noarch python-pulp-bindings-2.4.3-1.el7sat.noarch python-pulp-client-lib-2.4.3-1.el7sat.noarch python-pulp-common-2.4.3-1.el7sat.noarch python-pulp-puppet-common-2.4.3-1.el7sat.noarch python-pulp-rpm-common-2.4.3-1.el7sat.noarch python-qpid-0.22-15.el7.noarch python-qpid-qmf-0.22-37.el7.x86_64 qpid-cpp-client-0.22-42.el7.x86_64 qpid-cpp-server-0.22-42.el7.x86_64 qpid-cpp-server-linearstore-0.22-42.el7.x86_64 qpid-java-client-0.22-7.el7.noarch qpid-java-common-0.22-7.el7.noarch qpid-proton-c-0.7-2.el7.x86_64 qpid-qmf-0.22-37.el7.x86_64 qpid-tools-0.22-13.el7.noarch ruby193-rubygem-katello-1.5.0-93.el7sat.noarch rubygem-hammer_cli_katello-0.0.4-14.el7sat.noarch rubygem-smart_proxy_pulp-1.0.1-1.1.el7sat.noarch s6chima.usersys.redhat.com-qpid-broker-1.0-1.noarch s6chima.usersys.redhat.com-qpid-client-cert-1.0-1.noarch How reproducible: Steps to Reproduce: 1. install puppet on 2 a client and sync 2. check the db by doing below 3. Actual results: It looks like this is a bug because the client date is correct but puppet agent is storing the data on the database incorrectly: [root@s6chima data]# puppet agent -tv Warning: Setting manifest is deprecated in puppet.conf. See http://links.puppetlabs.com/env-settings-deprecations (at /usr/share/ruby/vendor_ruby/puppet/settings.rb:1095:in `block in issue_deprecations') Warning: Setting modulepath is deprecated in puppet.conf. See http://links.puppetlabs.com/env-settings-deprecations (at /usr/share/ruby/vendor_ruby/puppet/settings.rb:1095:in `block in issue_deprecations') Warning: Setting config_version is deprecated in puppet.conf. See http://links.puppetlabs.com/env-settings-deprecations (at /usr/share/ruby/vendor_ruby/puppet/settings.rb:1095:in `block in issue_deprecations') Info: Retrieving plugin Error: /File[/var/lib/puppet/lib]: Could not evaluate: Could not retrieve information from environment production source(s) puppet://s6chima.usersys.redhat.com/plugins Info: Caching catalog for s6chima.usersys.redhat.com Info: Applying configuration version '1421709200' Notice: Finished catalog run in 0.24 seconds Message Load (0.5ms) SELECT "messages".* FROM "messages" WHERE "messages"."digest" = '7240e6535102e088f32cbdd6dd1c58047be9ca84' LIMIT 1 Source Load (0.4ms) SELECT "sources".* FROM "sources" WHERE "sources"."digest" = '9191574fdd80d800fd950885475f6235b1e737b8' LIMIT 1 (0.1ms) BEGIN SQL (0.6ms) INSERT INTO "logs" ("created_at", "level_id", "message_id", "report_id", "source_id", "updated_at") VALUES ($1, $2, $3, $4, $5, $6) RETURNING "id" [["created_at", Mon, 19 Jan 2015 23:13:20 UTC +00:00], ["level_id", 4], ["message_id", 3], ["report_id", 712], ["source_id", 2], ["updated_at", Mon, 19 Jan 2015 23:13:20 UTC +00:00]] (7.6ms) COMMIT Message Load (0.5ms) SELECT "messages".* FROM "messages" WHERE "messages"."digest" = 'a259b4b60f2993b5b4622e8fb21a86f6fa59ba69' LIMIT 1 (0.1ms) BEGIN SQL (21.7ms) INSERT INTO "messages" ("digest", "value") VALUES ($1, $2) RETURNING "id" [["digest", "a259b4b60f2993b5b4622e8fb21a86f6fa59ba69"], ["value", "Caching catalog for s6chima.usersys.redhat.com"]] (17.0ms) COMMIT Source Load (0.5ms) SELECT "sources".* FROM "sources" WHERE "sources"."digest" = 'a100926532eb335a499d37a6bdb525c0d49ef68c' LIMIT 1 (0.1ms) BEGIN SQL (12.8ms) INSERT INTO "logs" ("created_at", "level_id", "message_id", "report_id", "source_id", "updated_at") VALUES ($1, $2, $3, $4, $5, $6) RETURNING "id" [["created_at", Mon, 19 Jan 2015 23:13:20 UTC +00:00], ["level_id", 1], ["message_id", 29], ["report_id", 712], ["source_id", 1], ["updated_at", Mon, 19 Jan 2015 23:13:20 UTC +00:00]] (38.0ms) COMMIT Message Load (0.4ms) SELECT "messages".* FROM "messages" WHERE "messages"."digest" = '571c5f613633d4208733a07a30224824315d8ffe' LIMIT 1 (0.1ms) BEGIN SQL (0.2ms) INSERT INTO "messages" ("digest", "value") VALUES ($1, $2) RETURNING "id" [["digest", "571c5f613633d4208733a07a30224824315d8ffe"], ["value", "Applying configuration version '1421709200'"]] (4.4ms) COMMIT Source Load (0.3ms) SELECT "sources".* FROM "sources" WHERE "sources"."digest" = 'a100926532eb335a499d37a6bdb525c0d49ef68c' LIMIT 1 (0.2ms) BEGIN SQL (0.4ms) INSERT INTO "logs" ("created_at", "level_id", "message_id", "report_id", "source_id", "updated_at") VALUES ($1, $2, $3, $4, $5, $6) RETURNING "id" [["created_at", Mon, 19 Jan 2015 23:13:20 UTC +00:00], ["level_id", 1], ["message_id", 30], ["report_id", 712], ["source_id", 1], ["updated_at", Mon, 19 Jan 2015 23:13:20 UTC +00:00]] (4.9ms) COMMIT foreman=# \d logs Table "public.logs" Column | Type | Modifiers ------------+-----------------------------+--------------------------------------------------- id | integer | not null default nextval('logs_id_seq'::regclass) source_id | integer | message_id | integer | report_id | integer | level_id | integer | created_at | timestamp without time zone | not null updated_at | timestamp without time zone | not null Indexes: "logs_pkey" PRIMARY KEY, btree (id) "index_logs_on_level_id" btree (level_id) "index_logs_on_message_id" btree (message_id) "index_logs_on_report_id" btree (report_id) We look here for the report: foreman=# select * from logs where id = 869; id | source_id | message_id | report_id | level_id | created_at | updated_at -----+-----------+------------+-----------+----------+----------------------------+---------------------------- 869 | 1 | 30 | 712 | 1 | 2015-01-19 23:13:20.868694 | 2015-01-19 23:13:20.868694 (1 row) foreman=# select * from messages where id = 30; id | value | digest ----+---------------------------------------------+------------------------------------------ 30 | Applying configuration version '1421709200' | 571c5f613633d4208733a07a30224824315d8ffe (1 row) Here we can see the date is wrong in the database but then we goto the client and verify the time is correct: foreman=# select * from reports where id = 712; id | host_id | reported_at | created_at | updated_at | status | metrics -----+---------+---------------------+----------------------------+----------------------------+--------+---------------------------------------------------------------- 712 | 1 | 2015-01-19 23:13:14 | 2015-01-19 23:13:20.661141 | 2015-01-19 23:13:20.661141 | 0 | --- !ruby/hash:ActionController::Parameters + | | | | | | resources: !ruby/hash:ActiveSupport::HashWithIndifferentAccess+ | | | | | | changed: 0 + | | | | | | failed: 0 + | | | | | | failed_to_restart: 0 + | | | | | | out_of_sync: 0 + | | | | | | restarted: 0 + | | | | | | scheduled: 0 + | | | | | | skipped: 0 + | | | | | | total: 1 + | | | | | | time: !ruby/hash:ActiveSupport::HashWithIndifferentAccess + | | | | | | config_retrieval: 1.555408091 + | | | | | | filebucket: 0.000179904 + | | | | | | total: 1.555587995 + | | | | | | changes: !ruby/hash:ActiveSupport::HashWithIndifferentAccess + | | | | | | total: 0 + | | | | | | events: !ruby/hash:ActiveSupport::HashWithIndifferentAccess + | | | | | | failure: 0 + | | | | | | success: 0 + | | | | | | total: 0 + | | | | | | (1 row) Time on machine: [root@s6chima ~]# date Mon Jan 19 18:21:06 EST 2015
Since this issue was entered in Red Hat Bugzilla, the release flag has been set to ? to ensure that it is properly evaluated for this release.
Created redmine issue http://projects.theforeman.org/issues/10316 from this bug
I am removing the link, as this is covered by 1187241. I am moving this to POST since 1187241 is in POST.
Verified in Satellite 6 Beta RC. Investigated over 50 reports and all are correctly showing the expected time.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2016:1500