Package: dash Version: 0.5.8-2.1ubuntu2 Severity: important Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? [VZ]I use a shell script to supervise processes in a docker/kubernetes container. I noticed steady growth in the cgroup's CPU utilization from 15 to 35 millicores within 17 days in absence of any external stimuli (dry run). If container got restarted, the pattern reappeared from the base level of 15 millicores. * What exactly did you do (or not do) that was effective (or ineffective)? [VZ]I reproduced the issue in local docker, sampled cgroup's threads with perf, and ran perf-diff on reports. It emerged that the CPU cost grew at dash's freejob() and kernel's copy_page() at page_fault(). The findings were consistent with dash growing a data structure, possibly the one indexed by nprocs at freejob(), on every iteration of the loop of the shell script. That data structure would have to be cloned at fork() happening along the loop, hence kernel page_faults. To verify my suspicions I reduced sleep inteval in the loop and monitored Resident Set Size. Reproduction steps without containers. The shell script: ----------------------------------------------------------------- #!/bin/sh cd /tmp while true do [ "`pgrep rsyslogd`" ] || service rsyslog start [ "`pgrep cron`" ] || service cron start [ "`pgrep sshd`" ] || service ssh start env >/root/env sleep .5 done ----------------------------------------------------------------- Save it as a file called woof, chmod it executable and run as # nohup ./woof & Monitoring with ps unveils unbound growth, e.g. (note the first figure): 1628 wait S ? 0:00 /bin/sh ./woof 3456 wait S ? 1:02 /bin/sh ./woof 5188 wait S ? 2:59 /bin/sh ./woof 6584 wait S ? 5:19 /bin/sh ./woof 7076 wait S ? 6:17 /bin/sh ./woof 9300 wait S ? 23:54 /bin/sh ./woof * What was the outcome of this action? [VZ]I had to resort to #!/bin/bash shebang as it rendered expected behaviour: 2684 wait S ? 0:00 /bin/bash ./woof 3896 wait S ? 1:32 /bin/bash ./woof 3896 wait S ? 3:10 /bin/bash ./woof 3896 wait S ? 3:45 /bin/bash ./woof 3896 pipe_w S ? 15:20 /bin/bash ./woof RSS remains constant at 3896 * What outcome did you expect instead? [VZ]I expect RSS of dash remains bound in the case of an infinite shell loop the same way as RSS of bash does. *** End of the template - remove these template lines *** -- System Information: Debian Release: stretch/sid APT prefers xenial-updates APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 'xenial'), (100, 'xenial-backports') Architecture: amd64 (x86_64) Kernel: Linux 4.4.0-1074-aws (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages dash depends on: ii debianutils 4.7 ii dpkg 1.18.4ubuntu1.4 ii libc6 2.23-0ubuntu10 dash recommends no packages. dash suggests no packages. -- debconf-show failed