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.)
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
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.
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
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
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
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
buildsys@lists.fedoraproject.org
-
Dan Williams -
Jeff Pitman -
seth vidal