Bug#689914: does funny things on short cksum output
On Fri, May 24, 2013 at 10:14:36AM -0600, Bob Proulx wrote: I assume you discovered this case by inspection of the code rather than in actual practice. This would be a very unlikely case to ever hit in real life. If it did then it would produce one spurious cron email out of years of runs. It happened on a real system often enough for me to notice, investigate and find the issue. Is it possible that cksum used to do a CRC16 some time ago? It certainly provides a bigger checksum nowadays, so the issue does probably not appear any more. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689914: does funny things on short cksum output
Hi Marc Good to know, thanks. Yes it is possible that it did a CRC16 check before. That would make sense as extracting the first five characters would have been a bit odd otherwise. Hope the problem is solved now. :-) // Ola On Mon, May 27, 2013 at 09:26:02AM +0200, Marc Haber wrote: On Fri, May 24, 2013 at 10:14:36AM -0600, Bob Proulx wrote: I assume you discovered this case by inspection of the code rather than in actual practice. This would be a very unlikely case to ever hit in real life. If it did then it would produce one spurious cron email out of years of runs. It happened on a real system often enough for me to notice, investigate and find the issue. Is it possible that cksum used to do a CRC16 some time ago? It certainly provides a bigger checksum nowadays, so the issue does probably not appear any more. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 -- --- Inguza Technology AB --- MSc in Information Technology / o...@inguza.comAnnebergsslingan 37\ | o...@debian.org 654 65 KARLSTAD| | http://inguza.com/Mobile: +46 (0)70-332 1551 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689914: does funny things on short cksum output
On Mon, May 27, 2013 at 06:44:16PM +0200, Ola Lundqvist wrote: Hope the problem is solved now. :-) I will open a new bug if it isn't ;-) Thanks for providing a great tool. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689914: does funny things on short cksum output
Ah! I missed that $$ part of the command. You are right, that would
have solved it too. Anyway %N is even better so I'll stick to the
uploaded variant.
// Ola
On Fri, May 24, 2013 at 08:48:03PM -0600, Bob Proulx wrote:
Hi Ola,
Ola Lundqvist wrote:
RANDOM=$(dd if=/dev/urandom count=1 2 /dev/null | cksum | awk
'{print$1}')
Splitting on whitespace is more resilient to input differences than
splitting on each space character. IMNHO using awk for field
selection is almost always better than using cut. The variations in
'wc' output is a good example of where awk works as desired but cut
would not.
Ah, I see. So if we happend to get a tab here cut would fail. In that case
Checked it and you are right.
ola@quartz:~/svn/fsp/cron-apt$ echo 1204231524$'\t'512
1204231524 512
ola@quartz:~/svn/fsp/cron-apt$ echo 1204231524$'\t'512 | awk '{print$1}'
1204231524
ola@quartz:~/svn/fsp/cron-apt$ echo 1204231524$'\t'512 | cut -d' ' -f1
1204231524 512
I think we should use awk as well. Good then I'll do so.
Yes. This is also just a general style of defensive shell scripting.
For example 'wc' notoriously has different output on different
systems. On some systems it has leading spaces and on others it does
not. And having experienced problems with differing whitespace from
various utilities I like to avoid being sensitive to them.
Since this has come up for discussion here it gives me an opportunity
to cringe once again at using /dev/*random and the unportability of
it and perhaps suggest using awk instead. In my own scripts I have
been using portable awk for generating random numbers. Therefore I
would suggest this instead and eliminate the use of /dev/*random.
Noting that in Debian this works with either mawk or gawk.
RANDOM=$(awk -v rs=$RUNSLEEP -v s=$$$(date +%M%S)
'BEGIN{srand(s);print(int(rs*rand()));}')
I do not really think this is a good approach. The reason is that you
initialize the random vector with the same minute and second every day.
Which means that you will end up in no randomness at all.
Your point about $(date +%M%S) being the same because this runs from
cron at the same time every day is a good one and one that I had
missed. In my application that isn't true but I failed to see that
point when suggesting it here. My bad.
However that is only half of the seed. The $$ is the other part of
the seed value. That will be different every run. Each time the
script is run it will get a different process id.
That is why I had originally had both $$ and $(date ...) so that
either one or the other would be different each time.
Command line test case:
$ awk -v rs=3600 -v s=$$$(date +%M%S)
'BEGIN{srand(s);print(int(rs*rand()));}'
1194
This is easy to see if you run the above command fast like this:
ola@quartz:~/svn/fsp/cron-apt$ awk -v rs=3600 -v s=$$$(date +%M%S)
'BEGIN{srand(s);print(int(rs*rand()));}'
82
ola@quartz:~/svn/fsp/cron-apt$ awk -v rs=3600 -v s=$$$(date +%M%S)
'BEGIN{srand(s);print(int(rs*rand()));}'
82
ola@quartz:~/svn/fsp/cron-apt$ awk -v rs=3600 -v s=$$$(date +%M%S)
'BEGIN{srand(s);print(int(rs*rand()));}'
555
ola@quartz:~/svn/fsp/cron-apt$ awk -v rs=3600 -v s=$$$(date +%M%S)
'BEGIN{srand(s);print(int(rs*rand()));}'
555
In the command line testing run the $$ is always the same process id.
It is the command shell's process id. But in a script that part would
always be different. In normal use in a script the seed would always
be different.
So thanks for the suggestion, but I'll stick to /dev/*random where
we know that we will get real random data.
That is fine of course. :-)
I can use this variant in case /dev/urandom does not exist...
Actually I will do that. However I will change +%M%S to +%N to have
better randomness in it.
Good plan. GNU date used in Debian includes %N. But in my application
I need it to run on HP-UX and IBM AIX and neither of those provide %N.
Changes are uploaded now.
I am sure that whatever you ended up using is fine. :-)
Bob
--
--- Inguza Technology AB --- MSc in Information Technology
/ o...@inguza.comAnnebergsslingan 37\
| o...@debian.org 654 65 KARLSTAD|
| http://inguza.com/Mobile: +46 (0)70-332 1551 |
\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
---
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689914: does funny things on short cksum output
Hi Marc Thanks. Ah, yes I did not think of that case. Will apply. // Ola On Sun, Oct 07, 2012 at 07:08:22PM +0200, Marc Haber wrote: Package: cron-apt Severity: normal Please consider the following patch: --- cron-apt.orig 2012-10-07 19:07:15.772153360 +0200 +++ cron-apt2012-10-07 19:07:32.748173175 +0200 @@ -299,7 +299,7 @@ if [ $RUNSLEEP -gt 0 ] ; then if [ -z $RANDOM ] ; then # A fix for shells that do not have this bash feature. - RANDOM=$(dd if=/dev/urandom count=1 2 /dev/null | cksum | cut -c1-5) + RANDOM=$(dd if=/dev/urandom count=1 2 /dev/null | cksum | cut -d' ' -f1) fi TIME=$(($RANDOM % $RUNSLEEP)) sleep $TIME which will help cron-apt to gracefully handle the case where the checksum returned by cksum is shorter than four digits. Greetings Marc -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.5.4-zgws1 (SMP w/8 CPU cores; PREEMPT) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- - Ola Lundqvist --- / o...@debian.org Annebergsslingan 37 \ | o...@inguza.com 654 65 KARLSTAD | | http://inguza.com/ +46 (0)70-332 1551 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689914: does funny things on short cksum output
Hi again I'm also adding Bob into this mail chain as he was the one that wrote the code for RANDOM in 2004. When testing this out I noticed the following: ola@quartz:~/svn/fsp/cron-apt$ dd if=/dev/urandom count=1 2 /dev/null | cksum 2815760522 512 ola@quartz:~/svn/fsp/cron-apt$ echo 2815760522 512 | cut -d' ' -f1 2815760522 ola@quartz:~/svn/fsp/cron-apt$ echo 2815760522 512 | cut -c1-5 28157 ola@quartz:~/svn/fsp/cron-apt$ echo $((2815760522 % 3600)) 2522 ola@quartz:~/svn/fsp/cron-apt$ echo $((28157 % 3600)) 2957 As you can see it gives different output. I do not really think that is a real problem, but I think you two should have the possibility to comment it before I apply the patch. Thanks, // Ola On Fri, May 24, 2013 at 01:01:20PM +0200, Ola Lundqvist wrote: Hi Marc Thanks. Ah, yes I did not think of that case. Will apply. // Ola On Sun, Oct 07, 2012 at 07:08:22PM +0200, Marc Haber wrote: Package: cron-apt Severity: normal Please consider the following patch: --- cron-apt.orig 2012-10-07 19:07:15.772153360 +0200 +++ cron-apt2012-10-07 19:07:32.748173175 +0200 @@ -299,7 +299,7 @@ if [ $RUNSLEEP -gt 0 ] ; then if [ -z $RANDOM ] ; then # A fix for shells that do not have this bash feature. - RANDOM=$(dd if=/dev/urandom count=1 2 /dev/null | cksum | cut -c1-5) + RANDOM=$(dd if=/dev/urandom count=1 2 /dev/null | cksum | cut -d' ' -f1) fi TIME=$(($RANDOM % $RUNSLEEP)) sleep $TIME which will help cron-apt to gracefully handle the case where the checksum returned by cksum is shorter than four digits. Greetings Marc -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.5.4-zgws1 (SMP w/8 CPU cores; PREEMPT) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- - Ola Lundqvist --- / o...@debian.org Annebergsslingan 37 \ | o...@inguza.com 654 65 KARLSTAD | | http://inguza.com/ +46 (0)70-332 1551 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- - Ola Lundqvist --- / o...@debian.org Annebergsslingan 37 \ | o...@inguza.com 654 65 KARLSTAD | | http://inguza.com/ +46 (0)70-332 1551 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689914: does funny things on short cksum output
Hi Ola, Marc,
Ola Lundqvist wrote:
I'm also adding Bob into this mail chain as he was the one that wrote the
code for RANDOM in 2004.
Actually I had suggested the randomization using $RANDOM in email in
May 2003 and after discussion with Ola it settled on using #!/bin/bash
to support it. I think it was released for use after Bug#191981 was
coincidentally reported soon afterward for the same reason. Giving
credit where credit is due David Weinehall suggested in Bug#260071 the
RANDOM fallback code currently in use with /dev/urandom cut which as
I recall allowed the script to return to #!/bin/sh. :-)
Marc Haber wrote:
Please consider the following patch:
- RANDOM=$(dd if=/dev/urandom count=1 2 /dev/null | cksum | cut
-c1-5)
+ RANDOM=$(dd if=/dev/urandom count=1 2 /dev/null | cksum | cut
-d' ' -f1)
which will help cron-apt to gracefully handle the case where the
checksum returned by cksum is shorter than four digits.
Ah... cksum prints the cksum with %u. If the cksum ever results in a
small integer then the width of the field may be shorter than four
characters. In that case the second field would be pulled into the
output since it is cutting strictly by fields. Here is a simulation.
$ echo 123 512 | cut -c1-5
123 5
I assume you discovered this case by inspection of the code rather
than in actual practice. This would be a very unlikely case to ever
hit in real life. If it did then it would produce one spurious cron
email out of years of runs. I have a test program running right now
looking for a random hit on this case and while it has been running
for some time now and generated many zillions of test cases I have yet
to produce a cksum shorter than four digits. Not impossible but
statistically extremely unlikely. Out of curiosity I will leave my
test case running for some more hours to see if I can produce an
example. I don't know if it will obtain one before the heat death of
the universe though.
- RANDOM=$(dd if=/dev/urandom count=1 2 /dev/null | cksum | cut
-c1-5)
+ RANDOM=$(dd if=/dev/urandom count=1 2 /dev/null | cksum | cut
-d' ' -f1)
If I had my preference I would use awk instead of cut for splitting
fields. Using awk is as standard as cut and so no difference in
dependencies. But for splitting fields on whitespace awk is a better
fit to the task than cut.
RANDOM=$(dd if=/dev/urandom count=1 2 /dev/null | cksum | awk '{print$1}')
Splitting on whitespace is more resilient to input differences than
splitting on each space character. IMNHO using awk for field
selection is almost always better than using cut. The variations in
'wc' output is a good example of where awk works as desired but cut
would not.
When testing this out I noticed the following:
...
As you can see it gives different output. I do not really think that is
a real problem, but I think you two should have the possibility to comment
it before I apply the patch.
This is okay. It is changing one random number for a different random
number. The generation of the arithmetic remainder of ARG1 divided by
ARG2 in the TIME=$(($RANDOM % $RUNSLEEP)) part washes the difference
away. The result will be a different random value between 0-$RUNSLEEP.
(And noting for the casual reader that RUNSLEEP defaults to 3600 and
so this gives a random delay across an hour interval. The cron job
runs in local time. As machines worldwide are located in different
timezones the load on the upstream repositories will be distributed
across the different timezones. Although some timezones will be more
populous than others.)
Since this has come up for discussion here it gives me an opportunity
to cringe once again at using /dev/*random and the unportability of
it and perhaps suggest using awk instead. In my own scripts I have
been using portable awk for generating random numbers. Therefore I
would suggest this instead and eliminate the use of /dev/*random.
Noting that in Debian this works with either mawk or gawk.
RANDOM=$(awk -v rs=$RUNSLEEP -v s=$$$(date +%M%S)
'BEGIN{srand(s);print(int(rs*rand()));}')
Command line test case:
$ awk -v rs=3600 -v s=$$$(date +%M%S) 'BEGIN{srand(s);print(int(rs*rand()));}'
1194
But I am unaware of any Debian kernel that doesn't support
/dev/*random and therefore do not feel strongly about it. Any
solution that works is okay with me.
Thanks Ola for maintaining cron-apt!
Bob
signature.asc
Description: Digital signature
Bug#689914: does funny things on short cksum output
Hi Bob
On Fri, May 24, 2013 at 10:14:36AM -0600, Bob Proulx wrote:
Hi Ola, Marc,
Ola Lundqvist wrote:
I'm also adding Bob into this mail chain as he was the one that wrote the
code for RANDOM in 2004.
Actually I had suggested the randomization using $RANDOM in email in
May 2003 and after discussion with Ola it settled on using #!/bin/bash
to support it. I think it was released for use after Bug#191981 was
coincidentally reported soon afterward for the same reason. Giving
credit where credit is due David Weinehall suggested in Bug#260071 the
RANDOM fallback code currently in use with /dev/urandom cut which as
I recall allowed the script to return to #!/bin/sh. :-)
:-)
Marc Haber wrote:
Please consider the following patch:
- RANDOM=$(dd if=/dev/urandom count=1 2 /dev/null | cksum |
cut -c1-5)
+ RANDOM=$(dd if=/dev/urandom count=1 2 /dev/null | cksum |
cut -d' ' -f1)
which will help cron-apt to gracefully handle the case where the
checksum returned by cksum is shorter than four digits.
Ah... cksum prints the cksum with %u. If the cksum ever results in a
small integer then the width of the field may be shorter than four
characters. In that case the second field would be pulled into the
output since it is cutting strictly by fields. Here is a simulation.
$ echo 123 512 | cut -c1-5
123 5
I assume you discovered this case by inspection of the code rather
than in actual practice. This would be a very unlikely case to ever
hit in real life. If it did then it would produce one spurious cron
email out of years of runs. I have a test program running right now
looking for a random hit on this case and while it has been running
for some time now and generated many zillions of test cases I have yet
to produce a cksum shorter than four digits. Not impossible but
statistically extremely unlikely. Out of curiosity I will leave my
test case running for some more hours to see if I can produce an
example. I don't know if it will obtain one before the heat death of
the universe though.
With enough people on the planet, maybe? In any case it is good to fix
a bug.
- RANDOM=$(dd if=/dev/urandom count=1 2 /dev/null | cksum |
cut -c1-5)
+ RANDOM=$(dd if=/dev/urandom count=1 2 /dev/null | cksum |
cut -d' ' -f1)
If I had my preference I would use awk instead of cut for splitting
fields. Using awk is as standard as cut and so no difference in
dependencies. But for splitting fields on whitespace awk is a better
fit to the task than cut.
That would do the trick as well.
RANDOM=$(dd if=/dev/urandom count=1 2 /dev/null | cksum | awk '{print$1}')
Splitting on whitespace is more resilient to input differences than
splitting on each space character. IMNHO using awk for field
selection is almost always better than using cut. The variations in
'wc' output is a good example of where awk works as desired but cut
would not.
Ah, I see. So if we happend to get a tab here cut would fail. In that case
Checked it and you are right.
ola@quartz:~/svn/fsp/cron-apt$ echo 1204231524$'\t'512
1204231524 512
ola@quartz:~/svn/fsp/cron-apt$ echo 1204231524$'\t'512 | awk '{print$1}'
1204231524
ola@quartz:~/svn/fsp/cron-apt$ echo 1204231524$'\t'512 | cut -d' ' -f1
1204231524 512
I think we should use awk as well. Good then I'll do so.
When testing this out I noticed the following:
...
As you can see it gives different output. I do not really think that is
a real problem, but I think you two should have the possibility to comment
it before I apply the patch.
This is okay. It is changing one random number for a different random
number. The generation of the arithmetic remainder of ARG1 divided by
ARG2 in the TIME=$(($RANDOM % $RUNSLEEP)) part washes the difference
away. The result will be a different random value between 0-$RUNSLEEP.
Great. That is what I thought. I just wanted to check if there were
some specific reason you just used the first digits.
(And noting for the casual reader that RUNSLEEP defaults to 3600 and
so this gives a random delay across an hour interval. The cron job
runs in local time. As machines worldwide are located in different
timezones the load on the upstream repositories will be distributed
across the different timezones. Although some timezones will be more
populous than others.)
Since this has come up for discussion here it gives me an opportunity
to cringe once again at using /dev/*random and the unportability of
it and perhaps suggest using awk instead. In my own scripts I have
been using portable awk for generating random numbers. Therefore I
would suggest this instead and eliminate the use of /dev/*random.
Noting that in Debian this works with either mawk or gawk.
RANDOM=$(awk -v rs=$RUNSLEEP -v s=$$$(date +%M%S)
'BEGIN{srand(s);print(int(rs*rand()));}')
I do not really think
Bug#689914: does funny things on short cksum output
Hi Ola,
Ola Lundqvist wrote:
RANDOM=$(dd if=/dev/urandom count=1 2 /dev/null | cksum | awk
'{print$1}')
Splitting on whitespace is more resilient to input differences than
splitting on each space character. IMNHO using awk for field
selection is almost always better than using cut. The variations in
'wc' output is a good example of where awk works as desired but cut
would not.
Ah, I see. So if we happend to get a tab here cut would fail. In that case
Checked it and you are right.
ola@quartz:~/svn/fsp/cron-apt$ echo 1204231524$'\t'512
1204231524 512
ola@quartz:~/svn/fsp/cron-apt$ echo 1204231524$'\t'512 | awk '{print$1}'
1204231524
ola@quartz:~/svn/fsp/cron-apt$ echo 1204231524$'\t'512 | cut -d' ' -f1
1204231524 512
I think we should use awk as well. Good then I'll do so.
Yes. This is also just a general style of defensive shell scripting.
For example 'wc' notoriously has different output on different
systems. On some systems it has leading spaces and on others it does
not. And having experienced problems with differing whitespace from
various utilities I like to avoid being sensitive to them.
Since this has come up for discussion here it gives me an opportunity
to cringe once again at using /dev/*random and the unportability of
it and perhaps suggest using awk instead. In my own scripts I have
been using portable awk for generating random numbers. Therefore I
would suggest this instead and eliminate the use of /dev/*random.
Noting that in Debian this works with either mawk or gawk.
RANDOM=$(awk -v rs=$RUNSLEEP -v s=$$$(date +%M%S)
'BEGIN{srand(s);print(int(rs*rand()));}')
I do not really think this is a good approach. The reason is that you
initialize the random vector with the same minute and second every day.
Which means that you will end up in no randomness at all.
Your point about $(date +%M%S) being the same because this runs from
cron at the same time every day is a good one and one that I had
missed. In my application that isn't true but I failed to see that
point when suggesting it here. My bad.
However that is only half of the seed. The $$ is the other part of
the seed value. That will be different every run. Each time the
script is run it will get a different process id.
That is why I had originally had both $$ and $(date ...) so that
either one or the other would be different each time.
Command line test case:
$ awk -v rs=3600 -v s=$$$(date +%M%S)
'BEGIN{srand(s);print(int(rs*rand()));}'
1194
This is easy to see if you run the above command fast like this:
ola@quartz:~/svn/fsp/cron-apt$ awk -v rs=3600 -v s=$$$(date +%M%S)
'BEGIN{srand(s);print(int(rs*rand()));}'
82
ola@quartz:~/svn/fsp/cron-apt$ awk -v rs=3600 -v s=$$$(date +%M%S)
'BEGIN{srand(s);print(int(rs*rand()));}'
82
ola@quartz:~/svn/fsp/cron-apt$ awk -v rs=3600 -v s=$$$(date +%M%S)
'BEGIN{srand(s);print(int(rs*rand()));}'
555
ola@quartz:~/svn/fsp/cron-apt$ awk -v rs=3600 -v s=$$$(date +%M%S)
'BEGIN{srand(s);print(int(rs*rand()));}'
555
In the command line testing run the $$ is always the same process id.
It is the command shell's process id. But in a script that part would
always be different. In normal use in a script the seed would always
be different.
So thanks for the suggestion, but I'll stick to /dev/*random where
we know that we will get real random data.
That is fine of course. :-)
I can use this variant in case /dev/urandom does not exist...
Actually I will do that. However I will change +%M%S to +%N to have
better randomness in it.
Good plan. GNU date used in Debian includes %N. But in my application
I need it to run on HP-UX and IBM AIX and neither of those provide %N.
Changes are uploaded now.
I am sure that whatever you ended up using is fine. :-)
Bob
signature.asc
Description: Digital signature
Bug#689914: does funny things on short cksum output
Package: cron-apt Severity: normal Please consider the following patch: --- cron-apt.orig 2012-10-07 19:07:15.772153360 +0200 +++ cron-apt2012-10-07 19:07:32.748173175 +0200 @@ -299,7 +299,7 @@ if [ $RUNSLEEP -gt 0 ] ; then if [ -z $RANDOM ] ; then # A fix for shells that do not have this bash feature. - RANDOM=$(dd if=/dev/urandom count=1 2 /dev/null | cksum | cut -c1-5) + RANDOM=$(dd if=/dev/urandom count=1 2 /dev/null | cksum | cut -d' ' -f1) fi TIME=$(($RANDOM % $RUNSLEEP)) sleep $TIME which will help cron-apt to gracefully handle the case where the checksum returned by cksum is shorter than four digits. Greetings Marc -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.5.4-zgws1 (SMP w/8 CPU cores; PREEMPT) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
