printenv eats up CPU.

[mythmon]

I originally reported this problem here: http://discuss.atom.io/t/weird-printenv-command-eating-up-cpu/8939

I'm running on Arch Linux. Sometimes I get processes like

/usr/bin/zsh -l -i -c $(printenv > /tmp/CommandRunner_fetchEnvOfLoginShell.txt)`

that never die and eventually grow to use 100% cpu. There are generally many of these processes running by the time I notice and kill them.

[yujinakayama]

Thanks for the report.

I've experienced the similar issue when I originally implemented CommandRunner on my OS X environment, and I added the subshell workaround $() then it was solved on OS X. However it seems that I should fix the underlying cause.

[ghost]

Any update on this? I have the same issue and it makes my machine sluggish. Updated to 0.14.4 and now it seems to only create 1 thread but that one still runs 100% and consumes a core.

[yujinakayama]

Nothing so far. I tried to reproduce the issue on Arch Linux before but no luck. It would be helpful if you could provide more detailed information.

[ghost]

Well i'm running a pretty much default installation of Antergos but I guess a key change is that I'm running zsh. I can't seem to reproduce the problem if i open a shell and run /usr/bin/zsh -l -i -c $(printenv > /tmp/CommandRunner_fetchEnvOfLoginShell.txt) manually but that is the command listed in system monitor. I'll see if I can dig a bit deeper. `

[mishak87]

I am running zsh having same issue.

/bin/sh -c /bin/zsh -l -i -c '$(printenv > /tmp/atom-lint_....txt)'

I have to send two sig term to kill it.

[martinb3]

I heard about how great this plugin was, but as soon as I installed it, my system load went up about 3x, and atom became unusable. Had tons of bash processes eating 100% CPU.

Process command line is: /bin/bash -l -i -c $(printenv > /tmp/atom-lint_f77dfd47036f433e0a44dbc228f76d3b4c8c4dc2.txt)

Running strace on it, it appears to be in a busy loop:

--- SIGTTIN {si_signo=SIGTTIN, si_code=SI_USER, si_pid=23322, si_uid=1000} ---
rt_sigaction(SIGTTIN, {SIG_IGN, [], SA_RESTORER, 0x7fb5b8d20c30}, {SIG_DFL, [], SA_RESTORER, 0x7fb5b8d20c30}, 8) = 0
ioctl(255, TIOCGPGRP, [24192])          = 0
rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x7fb5b8d20c30}, {SIG_IGN, [], SA_RESTORER, 0x7fb5b8d20c30}, 8) = 0
kill(0, SIGTTIN)                        = 0
--- SIGTTIN {si_signo=SIGTTIN, si_code=SI_USER, si_pid=23322, si_uid=1000} ---
rt_sigaction(SIGTTIN, {SIG_IGN, [], SA_RESTORER, 0x7fb5b8d20c30}, {SIG_DFL, [], SA_RESTORER, 0x7fb5b8d20c30}, 8) = 0
ioctl(255, TIOCGPGRP, [24192])          = 0
rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x7fb5b8d20c30}, {SIG_IGN, [], SA_RESTORER, 0x7fb5b8d20c30}, 8) = 0
kill(0, SIGTTIN)                        = 0
--- SIGTTIN {si_signo=SIGTTIN, si_code=SI_USER, si_pid=23322, si_uid=1000} ---
rt_sigaction(SIGTTIN, {SIG_IGN, [], SA_RESTORER, 0x7fb5b8d20c30}, {SIG_DFL, [], SA_RESTORER, 0x7fb5b8d20c30}, 8) = 0
ioctl(255, TIOCGPGRP, [24192])          = 0
rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x7fb5b8d20c30}, {SIG_IGN, [], SA_RESTORER, 0x7fb5b8d20c30}, 8) = 0
kill(0, SIGTTIN)                        = 0
--- SIGTTIN {si_signo=SIGTTIN, si_code=SI_USER, si_pid=23322, si_uid=1000} ---
rt_sigaction(SIGTTIN, {SIG_IGN, [], SA_RESTORER, 0x7fb5b8d20c30}, {SIG_DFL, [], SA_RESTORER, 0x7fb5b8d20c30}, 8) = 0
ioctl(255, TIOCGPGRP, [24192])          = 0
rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x7fb5b8d20c30}, {SIG_IGN, [], SA_RESTORER, 0x7fb5b8d20c30}, 8) = 0

No other syscalls but those, for 10+ minutes, in a tight loop.

[yujinakayama]

Hmm, I think I'll add an option to disable the auto PATH fetch feature (which causes this issue) as a workaround.

[yujinakayama]

I redesigned the handling of environment variables and released version 0.19.0. Could you check if it works in your environment? Also, please read the notice in the intallation instruction.

• https://github.com/yujinakayama/atom-lint#installation

[yujinakayama]

Closing. Reopen if you still have an issue.