Mock Patch to Enable Realtime Output of logs

[Jeff Pitman]

Hi:

This patch allows one to run "tail -f" on the build.log. It mostly 
re-uses existing variables and things like resultdir, etc. work 
properly.

Anyway, I hope to get this committed as this is a massive improvement 
from what mock had inherited. (Multiple mount/umount in root.log, but I 
don't think that many people care.  It's the simplest patch without 
taking in account of corner cases, etc.)

-- 
-jeff

[seth vidal]

On Sat, 2005-10-08 at 11:55 +0800, Jeff Pitman wrote:
>  Hi:
>  
>  This patch allows one to run "tail -f" on the build.log. It mostly 
>  re-uses existing variables and things like resultdir, etc. work 
>  properly.
>  
>  Anyway, I hope to get this committed as this is a massive improvement 
>  from what mock had inherited. (Multiple mount/umount in root.log, but I 
>  don't think that many people care.  It's the simplest patch without 
>  taking in account of corner cases, etc.) 
so commit it. :)

I believe you have commit access to mock.

I think a lot of folks would like this and I don't think it will break
plague's use in anyway.

-sv

[Jeff Pitman]

On Wednesday 19 October 2005 14:59, seth vidal wrote:
>  so commit it. :)
>
>  I believe you have commit access to mock. 
I do?! When did that happen? :P

There is one final problem that this patch does not cover. That is, when 
initializing the chroot and the log directory is not available yet.  
There's a bit of a buffering job done and then dumped to the log after 
the directory is created.

I need to use a lil imagination to make this happen. Currently, I got 
around this by dropping what is logged during the preliminary init 
stage. (Not really sure how much is logged, yet. Probably just some 
directory creates, etc.) Anyway, more polish is needed before commit.

-- 
-jeff

[seth vidal]

On Wed, 2005-10-19 at 15:12 +0800, Jeff Pitman wrote:
>  On Wednesday 19 October 2005 14:59, seth vidal wrote:
>  > so commit it. :)
>  >
>  > I believe you have commit access to mock.
>  
>  I do?! When did that happen? :P 
I think you do - try it out - check it out from fedora cvs and try a
commit :) If you don't have commit access I'll be glad to request it.


>  
>  There is one final problem that this patch does not cover. That is, when 
>  initializing the chroot and the log directory is not available yet.  
>  There's a bit of a buffering job done and then dumped to the log after 
>  the directory is created.
>  
>  I need to use a lil imagination to make this happen. Currently, I got 
>  around this by dropping what is logged during the preliminary init 
>  stage. (Not really sure how much is logged, yet. Probably just some 
>  directory creates, etc.) Anyway, more polish is needed before commit. 
Thanks,
-sv

[Dan Williams]

On Wed, 2005-10-19 at 15:12 +0800, Jeff Pitman wrote:
>  On Wednesday 19 October 2005 14:59, seth vidal wrote:
>  There is one final problem that this patch does not cover. That is, when 
>  initializing the chroot and the log directory is not available yet.  
>  There's a bit of a buffering job done and then dumped to the log after 
>  the directory is created. 
Got a final patch yet?  If you don't have commit privs I can do it.

I'm seeing issues right now in the fedora build system like this:

100      21961  0.0  0.2 71848 5232 ?        S    14:46   0:00 /usr/bin/python -tt
/usr/bin/mock -r fedora-3-x86_64-core --arch x86_64
--resultdir=/mnt/build/builder_work/b798c880f2
100      22916  0.0  0.0     0    0 ?        Z    14:48   0:00 [sh] <defunct>

[hammer1 ~]# strace -p 21961
Process 21961 attached - interrupt to quit
read(153,  <unfinished ...>
Process 21961 detached
[hammer1 ~]#

which I think could be avoided by not using commands.getstatusoutput().  Not sure though. 
Any other thoughts?

Dan

[seth vidal]

On Tue, 2005-10-25 at 16:16 -0400, Dan Williams wrote:
>  On Wed, 2005-10-19 at 15:12 +0800, Jeff Pitman wrote:
>  > On Wednesday 19 October 2005 14:59, seth vidal wrote:
>  > There is one final problem that this patch does not cover. That is, when 
>  > initializing the chroot and the log directory is not available yet.  
>  > There's a bit of a buffering job done and then dumped to the log after 
>  > the directory is created.
>  
>  Got a final patch yet?  If you don't have commit privs I can do it.
>  
>  I'm seeing issues right now in the fedora build system like this:
>  
>  100      21961  0.0  0.2 71848 5232 ?        S    14:46   0:00 /usr/bin/python -tt
> /usr/bin/mock -r fedora-3-x86_64-core --arch x86_64
> --resultdir=/mnt/build/builder_work/b798c880f2
>  100      22916  0.0  0.0     0    0 ?        Z    14:48   0:00 [sh] <defunct>
>  
>  [hammer1 ~]# strace -p 21961
>  Process 21961 attached - interrupt to quit
>  read(153,  <unfinished ...>
>  Process 21961 detached
>  [hammer1 ~]#
>  
>  which I think could be avoided by not using commands.getstatusoutput().  Not sure though.
>  Any other thoughts?
>   
why would they start happening now if they didn't happen before the
plague update?


-sv

[Dan Williams]

On Tue, 2005-10-25 at 16:20 -0400, seth vidal wrote:
>  On Tue, 2005-10-25 at 16:16 -0400, Dan Williams wrote:
>  > On Wed, 2005-10-19 at 15:12 +0800, Jeff Pitman wrote:
>  > > On Wednesday 19 October 2005 14:59, seth vidal wrote:
>  > > There is one final problem that this patch does not cover. That is, when 
>  > > initializing the chroot and the log directory is not available yet.  
>  > > There's a bit of a buffering job done and then dumped to the log after 
>  > > the directory is created.
>  > 
>  > Got a final patch yet?  If you don't have commit privs I can do it.
>  > 
>  > I'm seeing issues right now in the fedora build system like this:
>  > 
>  > 100      21961  0.0  0.2 71848 5232 ?        S    14:46   0:00 /usr/bin/python -tt
> /usr/bin/mock -r fedora-3-x86_64-core --arch x86_64
> --resultdir=/mnt/build/builder_work/b798c880f2
>  > 100      22916  0.0  0.0     0    0 ?        Z    14:48   0:00 [sh] <defunct>
>  > 
>  > [hammer1 ~]# strace -p 21961
>  > Process 21961 attached - interrupt to quit
>  > read(153,  <unfinished ...>
>  > Process 21961 detached
>  > [hammer1 ~]#
>  > 
>  > which I think could be avoided by not using commands.getstatusoutput().  Not sure
> though.  Any other thoughts?
>  > 
>  
>  why would they start happening now if they didn't happen before the
>  plague update? 
They did, just not quite as reproducibly I think...  It seems to hit it
on FC3 builds with gobby (ie, job 261), and I know I've seen this
before.

Dan