the exception is when sudo calls backupupload.js which already has timestamped
output because it uses node
an alternative idea is to maybe not use this flag at all and always parse the output.
this is a bit complicated since we have to look for a timestamp in a stream.
shell.sudo logs output to stdout/stderr intentionally. It is not meant
for scripts that generate much output (basically scripts/* files).
core of the issue is that none of the log commands require to use sudo.
they can just use normal tail. only app logs requires sudo because of the
logPaths directive in the manifest.
sudo forks and execs the program. sudo also hangs around as the parent of the program waiting on the program and also forwarding signals.
sudo does not forward signals when the originator comes from the same process group. recently, there has been a change where it will
forward signals as long as sudo or the command is not the group leader (https://www.sudo.ws/repos/sudo/rev/d1bf60eac57f)
for us, this means that calling kill from this node process doesn't work since it's in the same group (and ubuntu 22 doesn't have the above fix).
the workaround is to invoke a kill from a different process group and this is done by starting detached
another idea is: use "ps --pid cp.pid -o pid=" to get the pid of the command and then send it signal directly
see also: https://dxuuu.xyz/sudo.html
the gzip takes a lot of cpu processing and hogs the CPU. With a nice
level, we give other things higher priority.
An alternate idea that was explored was to use cpulimit. This is to
send SIGSTOP and SIGCONT periodically but this will not make use of the
CPU if it's idle (unlike nice).
Another idea is to use cgroups, but it's not clear how to use it with
the dynamic setup we have.
part of #691
Girish Ramakrishnan