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