Package: iputils-ping
Version: 3:20121221-5+b2
Severity: normal
Tags: upstream
Dear Maintainer,
Target System
=============
buster / testing
iputils-ping 3:20180629-2 armhf
Summary
=======
A process using ping with a count will hang/freeze for a period of time between
packets if the system time is bumped backwards by a significant amount.
This caused a number of high-availability (24/7) remotely deployed embedded
systems to freeze for nearly 24 hours when a running `chrony` (time daemon)
bumped the time back 24 hours (for some unknown reason - probably GPS NMEA data
stream related?).
How to reproduce
================
* Execute `ping -c 10 google.com`
* bump back system time `sudo date --set "-30 second"`
Notice a large (approx 30 seconds) pause between sending next request packet.
Expected
========
I expected a ping request packet to be sent every second,
regardless of any change in system time.
Workaround
==========
I had to workaround this using a bash for loop in a script and count of 1,
which is not ideal and shouldn't be required.
#!/bin/bash
for (( i = 0 ; i < 10 ; i++ )) ; do
ping -c 1 google.com
sleep 1
done
-- System Information:
Debian Release: 8.11
APT prefers oldstable
APT policy: (990, 'oldstable'), (500, 'oldstable-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf
Kernel: Linux 4.4.0-0.bpo.1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages iputils-ping depends on:
ii libc6 2.19-18+deb8u10
ii libcap2 1:2.24-8
ii libgnutls-openssl27 3.3.30-0+deb8u1
Versions of packages iputils-ping recommends:
ii libcap2-bin 1:2.24-8
iputils-ping suggests no packages.
-- no debconf information
