> You are changing the behavior of execWithCapture, you are now also
> capturing the stderr output!

Ah, whoops. See my comment below for how to fix it.

- Chris

>> @@ -93,17 +115,30 @@ def execWithCapture(command, argv, stdin = 0, stderr = 2, root='/'):
>> if type(stderr) == type("string"):
>> stderr = open(stderr, "w")
>> + runningLog = open("/tmp/program.log", "a")
>> + runningLog.write("Running... %s
" % ([command] + argv,))
>> +
>> try:
>> - pipe = subprocess.Popen([command] + argv, stdin=stdin,
>> + proc = subprocess.Popen([command] + argv, stdin=stdin,
>> stdout=subprocess.PIPE,
>> - stderr=subprocess.STDOUT,
>> + stderr=subprocess.PIPE,
>> preexec_fn=chroot, cwd=root)
>> +
>> + while True:
>> + (outStr, errStr) = proc.communicate()
>> + if outStr:
>> + runningLog.write(outStr)
>> + rc += outStr
>> + if errStr:
>> + runningLog.write(errStr)
>> + rc += errStr

Remove this rc += errStr and replace it with
sys.__stdout__.write(errStr). That at least gets us back to the
previous behavior of not capturing stderr. What we probably should do
is write it to wherever the stderr parameter tells us to - we even open
a location for it above, but never do anything with it.

>> +
>> + if proc.returncode is not None:
>> + break
>> except OSError, (errno, msg):
>> log.error ("Error running " + command + ": " + msg)
>> raise RuntimeError, "Error running " + command + ": " + msg
>> - rc = pipe.stdout.read()
>> - pipe.wait()
>> return rc
>> def execWithPulseProgress(command, argv, stdin = 0, stdout = 1,
>> stderr = 2,

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

> Yes, please, for the love of god do not let stderr just fall to the
> floor. In a log file and to a tty somewhere would be best (so that you
> can see it even if you can't get to the log file)

You might think I'm crazy, but what I would really like to do here is
spawn a tail -f process on log files on various ttys from init, rather
than having to play all these output redirection games ourselves.

- Chris

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Chris Lumens wrote:

Yes, please, for the love of god do not let stderr just fall to the
floor. In a log file and to a tty somewhere would be best (so that you
can see it even if you can't get to the log file)


You might think I'm crazy, but what I would really like to do here is
spawn a tail -f process on log files on various ttys from init, rather
than having to play all these output redirection games ourselves.



Not crazy at all,
/me likes it

Regards,

Hans

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

On Wed, Jan 07, 2009 at 10:20:14AM -0500, Jesse Keating wrote:
> On Wed, 2009-01-07 at 10:15 -0500, Chris Lumens wrote:
> >
> > You might think I'm crazy, but what I would really like to do here is
> > spawn a tail -f process on log files on various ttys from init, rather
> > than having to play all these output redirection games ourselves.
>
> WORKSFORME

Its possible some output might be buffered and not shown by tail -f
in time before something crashes...

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Hans de Goede (hdegoede@redhat.com) said:
>> You might think I'm crazy, but what I would really like to do here is
>> spawn a tail -f process on log files on various ttys from init, rather
>> than having to play all these output redirection games ourselves.
>
> Not crazy at all,
> /me likes it

Just steal the plymouth boot logging code?

Bill

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Chris Lumens wrote:
You are changing the behavior of execWithCapture, you are now also
capturing the stderr output!


Ah, whoops. See my comment below for how to fix it.

- Chris


@@ -93,17 +115,30 @@ def execWithCapture(command, argv, stdin = 0, stderr = 2, root='/'):
if type(stderr) == type("string"):
stderr = open(stderr, "w")
+ runningLog = open("/tmp/program.log", "a")
+ runningLog.write("Running... %s
" % ([command] + argv,))
+
try:
- pipe = subprocess.Popen([command] + argv, stdin=stdin,
+ proc = subprocess.Popen([command] + argv, stdin=stdin,
stdout=subprocess.PIPE,
- stderr=subprocess.STDOUT,
+ stderr=subprocess.PIPE,
preexec_fn=chroot, cwd=root)
+
+ while True:
+ (outStr, errStr) = proc.communicate()
+ if outStr:
+ runningLog.write(outStr)
+ rc += outStr
+ if errStr:
+ runningLog.write(errStr)
+ rc += errStr


Remove this rc += errStr and replace it with
sys.__stdout__.write(errStr). That at least gets us back to the
previous behavior of not capturing stderr. What we probably should do
is write it to wherever the stderr parameter tells us to - we even open
a location for it above, but never do anything with it.



Seems like an ok solution, but it would be better to log it to the specified
file, while we are making changes.


Regards,

Hans

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

> > Remove this rc += errStr and replace it with
> > sys.__stdout__.write(errStr). That at least gets us back to the
> > previous behavior of not capturing stderr.
>
> Oops, sys isn't defined here. Causing tracebacks in rawhide.

Fixed.

- Chris

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list