Move logic to log to files from `repy.py` to `nmAPI.py`?

[aaaaalbert]

repy.py currently takes two optional command-line arguments to control certain aspects of logging, set by the nodemanager when launching a sandbox:

• The --logfile option controls where things go that sandboxed programs print using the log() RepyV2 call, and
• the --servicelog option makes certain rare internal error messages from tracebackrepy.py go to the nodemanager log.

This introduces complexity in the Repy sandbox, so that it imports the proper logging libraries, finds log files, does log rotation, etc.

Instead, I think that the nodemanager should take care of this by redirecting the sandbox's standard streams appropriately. The Repy sandbox would get somewhat simpler; the nodemanager and sandbox separated more clearly (see also SeattleTestbed/nodemanager#119).

Furthermore, we could support much more easily other, non-Repy sandbox types that were not built with setting up logging in mind, and have things like seash's show log work transparently for them too.

What's your impression? Is this worthwhile?

[JustinCappos]

How do we handle a program that does:

while True:
log('JUNK!\n')

On Tue, Aug 11, 2015 at 11:12 AM, aaaaalbert notifications@github.com
wrote:

repy.py currently takes two optional command-line arguments to control
certain aspects of logging, set by the nodemanager
https://github.com/SeattleTestbed/nodemanager/blob/master/nmAPI.py#L379-L388
when launching a sandbox:

• The --logfile option
  https://github.com/SeattleTestbed/repy_v2/blob/master/repy.py#L34
  controls where things go that sandboxed programs print using the log()
  RepyV2 call, and
• the --servicelog option
  https://github.com/SeattleTestbed/repy_v2/blob/master/repy.py#L40
  makes certain rare internal error messages from tracebackrepy.py go to
  the nodemanager log.

This introduces complexity in the Repy sandbox, so that it imports the
proper logging libraries, finds log files, does log rotation, etc.

Instead, I think that the nodemanager should take care of this by
redirecting the sandbox's standard streams appropriately. The Repy sandbox
would get somewhat simpler; the nodemanager and sandbox separated more
clearly (see also SeattleTestbed/nodemanager#119
SeattleTestbed/nodemanager#119).

Furthermore, we could support much more easily other, non-Repy sandbox
types that were not built with setting up logging in mind, and have things
like seash's show log work transparently for them too.

What's your impression? Is this worthwhile?

—
Reply to this email directly or view it on GitHub
#103.

[aaaaalbert]

I'll assume we let this snippet run as a sandboxed program. Then, depending on how it is started,

• Running it without the --logfile arg (as is typical in interactive / command line use). it just prints to stdout, with the appropriate nanny lograte.
• If the --logfile arg is given when the sandbox is started, then the output is redirected to the log file, rate-limited, rotated, etc.

The arg is usually only passed when the nodemanager starts the sandbox.