| 2015-03-07 17:16:03 |
sgofferj |
bug |
|
|
added bug |
| 2015-03-07 17:16:21 |
sgofferj |
affects |
tftp-hpa (Ubuntu) |
cron (Ubuntu) |
|
| 2015-06-08 09:21:21 |
Launchpad Janitor |
cron (Ubuntu): status |
New |
Confirmed |
|
| 2015-06-08 09:22:49 |
G.J. |
bug |
|
|
added subscriber G.J. |
| 2015-06-09 08:52:31 |
G.J. |
affects |
cron (Ubuntu) |
rsyslog (Ubuntu) |
|
| 2015-09-24 07:20:47 |
Frank Agerholm |
bug |
|
|
added subscriber Frank Agerholm |
| 2016-02-26 12:44:38 |
Ingo Dyck |
bug |
|
|
added subscriber Ingo Dyck |
| 2017-05-27 12:57:45 |
Dominique Poulain |
bug |
|
|
added subscriber Dominique Poulain |
| 2017-07-17 08:51:20 |
Seyeong Kim |
nominated for series |
|
Ubuntu Trusty |
|
| 2017-07-17 09:29:50 |
Seyeong Kim |
description |
On my main server I see unexplainable time jumps backwards in the syslog. Those jumps affect CRON.
Example:
Feb 10 06:48:01 nostromo CRON[20351]: (root) CMD ( /storage/exec/checkinternet.sh 2>/dev/null 1>/dev/null)
Feb 10 06:49:01 nostromo CRON[20364]: (root) CMD ( /storage/exec/checkinternet.sh 2>/dev/null 1>/dev/null)
Feb 10 06:50:01 nostromo CRON[20386]: (root) CMD ( /storage/exec/status-nostromo.sh >/dev/null 2>&1)
Feb 7 05:40:01 nostromo CRON[20389]: (root) CMD ( /storage/exec/checkinternet.sh 2>/dev/null 1>/dev/null)
Feb 10 06:50:01 nostromo CRON[20390]: (root) CMD ( /storage/exec/checkinternet.sh 2>/dev/null 1>/dev/null)
Feb 10 06:50:01 nostromo CRON[20391]: (root) CMD ( /storage/exec/checkip.sh 2>/dev/null 1>/dev/null)
For debugging I did the following:
Start xclock and watch xclock and tail -f /var/log/syslog in parallel. When CRON logged a wrong time, xclock did NOT show any time jump but seemed to freeze for a fraction of a second.
Open a screen and start a script that will once per second read the time (in unix seconds) and compare the read time with the time read a second ago. If the current time was smaller, the script would send an email with a process list from before and after the jump. The script also never detected any time jump.
In summary, my current impression is that there might be a bug in CRON because no other programm seems to be able to see the "wrong" time. The server in question is syslog server for 4 servers and 3 network devices. The time jumps exclusively show in syslog entries from the local CRON instance. Not in any remote syslog entry and not in any other local syslog entry, e.g. from DHCPD, bind, tftpd, etc. etc.
Also, after a reboot, things work ok for several days upto about 2 or 3 weeks. Then the "time jumps" start to occur with increasing frequency.
I don't use user crontabs but maintain all jobs in /etc/crontab. I have number of jobs which are triggered every minute and another number of jobs which are triggered every 5 minutes (maybe some CRON internal counter overflow problem?).
Hardware:
Asus P9D-V
Intel Xeon E3-1240L V3
16GB ECC RAM
128GB SSD System
3x3TB ZFS RaidZ2 storage
1x3TB Misc. data
CMOS battery already changed and board inspected.
nostromo:~ # lsb_release -rd
Description: Ubuntu 14.04.2 LTS
Release: 14.04
nostromo:~ # apt-cache policy cron
cron:
Installed: 3.0pl1-124ubuntu2
Candidate: 3.0pl1-124ubuntu2
Version table:
*** 3.0pl1-124ubuntu2 0
500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
100 /var/lib/dpkg/status |
[Impact]
on Trusty
logging to syslog via cron causes timestamp abnormals after several hours.
[Test Case]
1. run below first,
while true ; do logger "hello syslog" ; sleep 1; done
2. register below script to crontab
for i in {1..100} ; do logger "hello syslog via cron" ; sleep 1; done
3. monitor syslog with below script
tail -f -n 100 /var/log/syslog
You can see weird timestamp in several hours.
[Regression Potential]
it's ratelimiting turn off code, could be issue with being off rate-limit
[Other Info]
commit
From 7a2e2473476d2b10a775affd9ac6c62b81c450e5 Mon Sep 17 00:00:00 2001
From: Tomas Heinrich <theinric@redhat.com>
Date: Thu, 24 Jul 2014 13:47:14 +0200
Subject: [PATCH 1/1] bugfix: plug a memleak in imuxsock
The hash table for the system socket was allocated twice. The other
one being in activateListeners().
This commit practically reverts: 34a77cde2423303da72ab773128a2ddcf41
The issue seems to be that the hash table is not initialized (to NULL)
rather then not being allocated.
#####################################################################
## old description
On my main server I see unexplainable time jumps backwards in the syslog. Those jumps affect CRON.
Example:
Feb 10 06:48:01 nostromo CRON[20351]: (root) CMD ( /storage/exec/checkinternet.sh 2>/dev/null 1>/dev/null)
Feb 10 06:49:01 nostromo CRON[20364]: (root) CMD ( /storage/exec/checkinternet.sh 2>/dev/null 1>/dev/null)
Feb 10 06:50:01 nostromo CRON[20386]: (root) CMD ( /storage/exec/status-nostromo.sh >/dev/null 2>&1)
Feb 7 05:40:01 nostromo CRON[20389]: (root) CMD ( /storage/exec/checkinternet.sh 2>/dev/null 1>/dev/null)
Feb 10 06:50:01 nostromo CRON[20390]: (root) CMD ( /storage/exec/checkinternet.sh 2>/dev/null 1>/dev/null)
Feb 10 06:50:01 nostromo CRON[20391]: (root) CMD ( /storage/exec/checkip.sh 2>/dev/null 1>/dev/null)
For debugging I did the following:
Start xclock and watch xclock and tail -f /var/log/syslog in parallel. When CRON logged a wrong time, xclock did NOT show any time jump but seemed to freeze for a fraction of a second.
Open a screen and start a script that will once per second read the time (in unix seconds) and compare the read time with the time read a second ago. If the current time was smaller, the script would send an email with a process list from before and after the jump. The script also never detected any time jump.
In summary, my current impression is that there might be a bug in CRON because no other programm seems to be able to see the "wrong" time. The server in question is syslog server for 4 servers and 3 network devices. The time jumps exclusively show in syslog entries from the local CRON instance. Not in any remote syslog entry and not in any other local syslog entry, e.g. from DHCPD, bind, tftpd, etc. etc.
Also, after a reboot, things work ok for several days upto about 2 or 3 weeks. Then the "time jumps" start to occur with increasing frequency.
I don't use user crontabs but maintain all jobs in /etc/crontab. I have number of jobs which are triggered every minute and another number of jobs which are triggered every 5 minutes (maybe some CRON internal counter overflow problem?).
Hardware:
Asus P9D-V
Intel Xeon E3-1240L V3
16GB ECC RAM
128GB SSD System
3x3TB ZFS RaidZ2 storage
1x3TB Misc. data
CMOS battery already changed and board inspected.
nostromo:~ # lsb_release -rd
Description: Ubuntu 14.04.2 LTS
Release: 14.04
nostromo:~ # apt-cache policy cron
cron:
Installed: 3.0pl1-124ubuntu2
Candidate: 3.0pl1-124ubuntu2
Version table:
*** 3.0pl1-124ubuntu2 0
500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
100 /var/lib/dpkg/status |
|
| 2017-07-17 09:44:05 |
Seyeong Kim |
attachment added |
|
lp1429427_trusty.debdiff https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1429427/+attachment/4916080/+files/lp1429427_trusty.debdiff |
|
| 2017-07-17 09:44:22 |
Seyeong Kim |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2017-07-17 09:44:33 |
Seyeong Kim |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2017-07-17 09:45:05 |
Seyeong Kim |
description |
[Impact]
on Trusty
logging to syslog via cron causes timestamp abnormals after several hours.
[Test Case]
1. run below first,
while true ; do logger "hello syslog" ; sleep 1; done
2. register below script to crontab
for i in {1..100} ; do logger "hello syslog via cron" ; sleep 1; done
3. monitor syslog with below script
tail -f -n 100 /var/log/syslog
You can see weird timestamp in several hours.
[Regression Potential]
it's ratelimiting turn off code, could be issue with being off rate-limit
[Other Info]
commit
From 7a2e2473476d2b10a775affd9ac6c62b81c450e5 Mon Sep 17 00:00:00 2001
From: Tomas Heinrich <theinric@redhat.com>
Date: Thu, 24 Jul 2014 13:47:14 +0200
Subject: [PATCH 1/1] bugfix: plug a memleak in imuxsock
The hash table for the system socket was allocated twice. The other
one being in activateListeners().
This commit practically reverts: 34a77cde2423303da72ab773128a2ddcf41
The issue seems to be that the hash table is not initialized (to NULL)
rather then not being allocated.
#####################################################################
## old description
On my main server I see unexplainable time jumps backwards in the syslog. Those jumps affect CRON.
Example:
Feb 10 06:48:01 nostromo CRON[20351]: (root) CMD ( /storage/exec/checkinternet.sh 2>/dev/null 1>/dev/null)
Feb 10 06:49:01 nostromo CRON[20364]: (root) CMD ( /storage/exec/checkinternet.sh 2>/dev/null 1>/dev/null)
Feb 10 06:50:01 nostromo CRON[20386]: (root) CMD ( /storage/exec/status-nostromo.sh >/dev/null 2>&1)
Feb 7 05:40:01 nostromo CRON[20389]: (root) CMD ( /storage/exec/checkinternet.sh 2>/dev/null 1>/dev/null)
Feb 10 06:50:01 nostromo CRON[20390]: (root) CMD ( /storage/exec/checkinternet.sh 2>/dev/null 1>/dev/null)
Feb 10 06:50:01 nostromo CRON[20391]: (root) CMD ( /storage/exec/checkip.sh 2>/dev/null 1>/dev/null)
For debugging I did the following:
Start xclock and watch xclock and tail -f /var/log/syslog in parallel. When CRON logged a wrong time, xclock did NOT show any time jump but seemed to freeze for a fraction of a second.
Open a screen and start a script that will once per second read the time (in unix seconds) and compare the read time with the time read a second ago. If the current time was smaller, the script would send an email with a process list from before and after the jump. The script also never detected any time jump.
In summary, my current impression is that there might be a bug in CRON because no other programm seems to be able to see the "wrong" time. The server in question is syslog server for 4 servers and 3 network devices. The time jumps exclusively show in syslog entries from the local CRON instance. Not in any remote syslog entry and not in any other local syslog entry, e.g. from DHCPD, bind, tftpd, etc. etc.
Also, after a reboot, things work ok for several days upto about 2 or 3 weeks. Then the "time jumps" start to occur with increasing frequency.
I don't use user crontabs but maintain all jobs in /etc/crontab. I have number of jobs which are triggered every minute and another number of jobs which are triggered every 5 minutes (maybe some CRON internal counter overflow problem?).
Hardware:
Asus P9D-V
Intel Xeon E3-1240L V3
16GB ECC RAM
128GB SSD System
3x3TB ZFS RaidZ2 storage
1x3TB Misc. data
CMOS battery already changed and board inspected.
nostromo:~ # lsb_release -rd
Description: Ubuntu 14.04.2 LTS
Release: 14.04
nostromo:~ # apt-cache policy cron
cron:
Installed: 3.0pl1-124ubuntu2
Candidate: 3.0pl1-124ubuntu2
Version table:
*** 3.0pl1-124ubuntu2 0
500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
100 /var/lib/dpkg/status |
[Impact]
on Trusty
logging to syslog via cron causes timestamp abnormals after several hours.
[Test Case]
1. run below first,
while true ; do logger "hello syslog" ; sleep 1; done
2. register below script to crontab
for i in {1..100} ; do logger "hello syslog via cron" ; sleep 1; done
3. monitor syslog with below script
tail -f -n 100 /var/log/syslog
You can see weird timestamp in several hours.
[Regression Potential]
it's ratelimiting turn off code, could be issue with being off rate-limit
[Other Info]
below commit fixes this issue in my test
From 7a2e2473476d2b10a775affd9ac6c62b81c450e5 Mon Sep 17 00:00:00 2001
From: Tomas Heinrich <theinric@redhat.com>
Date: Thu, 24 Jul 2014 13:47:14 +0200
Subject: [PATCH 1/1] bugfix: plug a memleak in imuxsock
The hash table for the system socket was allocated twice. The other
one being in activateListeners().
This commit practically reverts: 34a77cde2423303da72ab773128a2ddcf41
The issue seems to be that the hash table is not initialized (to NULL)
rather then not being allocated.
#####################################################################
## old description
On my main server I see unexplainable time jumps backwards in the syslog. Those jumps affect CRON.
Example:
Feb 10 06:48:01 nostromo CRON[20351]: (root) CMD ( /storage/exec/checkinternet.sh 2>/dev/null 1>/dev/null)
Feb 10 06:49:01 nostromo CRON[20364]: (root) CMD ( /storage/exec/checkinternet.sh 2>/dev/null 1>/dev/null)
Feb 10 06:50:01 nostromo CRON[20386]: (root) CMD ( /storage/exec/status-nostromo.sh >/dev/null 2>&1)
Feb 7 05:40:01 nostromo CRON[20389]: (root) CMD ( /storage/exec/checkinternet.sh 2>/dev/null 1>/dev/null)
Feb 10 06:50:01 nostromo CRON[20390]: (root) CMD ( /storage/exec/checkinternet.sh 2>/dev/null 1>/dev/null)
Feb 10 06:50:01 nostromo CRON[20391]: (root) CMD ( /storage/exec/checkip.sh 2>/dev/null 1>/dev/null)
For debugging I did the following:
Start xclock and watch xclock and tail -f /var/log/syslog in parallel. When CRON logged a wrong time, xclock did NOT show any time jump but seemed to freeze for a fraction of a second.
Open a screen and start a script that will once per second read the time (in unix seconds) and compare the read time with the time read a second ago. If the current time was smaller, the script would send an email with a process list from before and after the jump. The script also never detected any time jump.
In summary, my current impression is that there might be a bug in CRON because no other programm seems to be able to see the "wrong" time. The server in question is syslog server for 4 servers and 3 network devices. The time jumps exclusively show in syslog entries from the local CRON instance. Not in any remote syslog entry and not in any other local syslog entry, e.g. from DHCPD, bind, tftpd, etc. etc.
Also, after a reboot, things work ok for several days upto about 2 or 3 weeks. Then the "time jumps" start to occur with increasing frequency.
I don't use user crontabs but maintain all jobs in /etc/crontab. I have number of jobs which are triggered every minute and another number of jobs which are triggered every 5 minutes (maybe some CRON internal counter overflow problem?).
Hardware:
Asus P9D-V
Intel Xeon E3-1240L V3
16GB ECC RAM
128GB SSD System
3x3TB ZFS RaidZ2 storage
1x3TB Misc. data
CMOS battery already changed and board inspected.
nostromo:~ # lsb_release -rd
Description: Ubuntu 14.04.2 LTS
Release: 14.04
nostromo:~ # apt-cache policy cron
cron:
Installed: 3.0pl1-124ubuntu2
Candidate: 3.0pl1-124ubuntu2
Version table:
*** 3.0pl1-124ubuntu2 0
500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
100 /var/lib/dpkg/status |
|
| 2017-07-17 09:47:14 |
Seyeong Kim |
rsyslog (Ubuntu): status |
Confirmed |
Fix Released |
|
| 2017-07-17 09:48:54 |
Seyeong Kim |
tags |
|
sts |
|
| 2017-07-17 13:56:57 |
Eric Desrochers |
bug task added |
|
rsyslog (Ubuntu Trusty) |
|
| 2017-07-17 13:57:09 |
Eric Desrochers |
rsyslog (Ubuntu Trusty): assignee |
|
Seyeong Kim (xtrusia) |
|
| 2017-07-17 13:57:12 |
Eric Desrochers |
rsyslog (Ubuntu Trusty): importance |
Undecided |
Medium |
|
| 2017-07-17 13:57:27 |
Eric Desrochers |
tags |
sts |
sts sts-sru-needed |
|
| 2017-07-17 16:29:44 |
Eric Desrochers |
bug |
|
|
added subscriber Eric Desrochers |
| 2017-07-18 10:30:44 |
Seyeong Kim |
attachment added |
|
lp1429427_trusty2.debdiff https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1429427/+attachment/4916721/+files/lp1429427_trusty2.debdiff |
|
| 2017-07-18 13:18:41 |
Eric Desrochers |
rsyslog (Ubuntu Trusty): status |
New |
In Progress |
|
| 2017-07-18 13:18:51 |
Eric Desrochers |
bug |
|
|
added subscriber SRU Verification |
| 2017-07-19 15:47:26 |
Robie Basak |
rsyslog (Ubuntu Trusty): status |
In Progress |
Fix Committed |
|
| 2017-07-19 15:47:30 |
Robie Basak |
tags |
sts sts-sru-needed |
sts sts-sru-needed verification-needed verification-needed-trusty |
|
| 2017-07-19 15:47:59 |
Robie Basak |
removed subscriber Ubuntu Sponsors Team |
|
|
|
| 2017-07-20 01:21:52 |
Seyeong Kim |
tags |
sts sts-sru-needed verification-needed verification-needed-trusty |
sts sts-sru-needed verification-done-trusty verification-needed |
|
| 2017-07-27 14:17:45 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2017-07-27 14:27:46 |
Launchpad Janitor |
rsyslog (Ubuntu Trusty): status |
Fix Committed |
Fix Released |
|
