1 |
Hi, |
2 |
|
3 |
On Tue, 07 Mar 2023 09:01:34 +0000 |
4 |
Michael <confabulate@××××××××.com> wrote: |
5 |
|
6 |
> On Tuesday, 7 March 2023 07:52:01 GMT Mickaël Bucas wrote: |
7 |
> > Le mar. 7 mars 2023 à 05:36, Bryan Gardiner <bog@××××××.net> a |
8 |
> > écrit : |
9 |
> > > Hi folks, |
10 |
> > > |
11 |
> > > How can I follow Portage's compressed build logs in real time as |
12 |
> > > they are generated? |
13 |
> > > |
14 |
> > > ... |
15 |
> > > |
16 |
> > > tail -c +1 -f build.log.gz | od -t x1 |
17 |
> > > |
18 |
> > > but the following hangs with no output: |
19 |
> > > tail -c +1 -f build.log.gz | gunzip |
20 |
> > |
21 |
> > Reading the man page, "zless" is just a wrapper around "less". |
22 |
|
23 |
Neat, zless is a lot simpler than I thought. |
24 |
|
25 |
> > So it should support the same options including typing "F" at the |
26 |
> > end of a file to keep trying to read when the end of file is |
27 |
> > reached. |
28 |
> > |
29 |
> > I made a small test, but it didn't work: |
30 |
> > # Create a growing file |
31 |
> > $ yes | nl | gzip > zless-test.gz & |
32 |
> > # Try to follow at the end |
33 |
> > $ zless zless-test.gz |
34 |
> > |
35 |
> > With ">" to go to the end and "F" to continue, I didn't get the |
36 |
> > expected behavior, it stood still at the point I was viewing. |
37 |
> > I don't know if it's really a bug or if I made a mistake... |
38 |
> > (Don't forget to stop the growing file :) ) |
39 |
|
40 |
I suppose it makes sense that a simple "gunzip -c file.gz | less" |
41 |
doesn't work, assuming zless is equivalent to that. gunzip sees the |
42 |
end of the file and exits rather than waiting for additional content. |
43 |
Then less sees its pipe close. |
44 |
|
45 |
So I think the "tail -c +1 -f build.log.gz" bit is needed, and appears |
46 |
to work since od shows data appended every few seconds. |
47 |
|
48 |
> You could try: |
49 |
> |
50 |
> tail -c +1 -f build.log.gz | gunzip | less |
51 |
> |
52 |
> I think it should work, but I haven't tried it. |
53 |
|
54 |
Thanks, but I suspect that less is still at the whim of gunzip here, |
55 |
and gunzip isn't producing anything. |
56 |
|
57 |
Maybe gunzip just has a massive output buffer. If I do something a bit |
58 |
more complicated: |
59 |
|
60 |
(N=0; while true; do |
61 |
(( N++ )) |
62 |
echo "$N" | gzip |
63 |
if (( N % 4000 == 0 )); then sleep 1; fi |
64 |
done) | gunzip | od -A d -t x1 |
65 |
|
66 |
then nothing is shown for 15 seconds or so, then od quickly dumps |
67 |
51952 bytes of hex output, then another long pause before dumping |
68 |
another 60480 bytes of hex. If I try this with "pigz -cd" instead of |
69 |
"gunzip" then output starts flowing after just ~400 bytes, but sadly |
70 |
that still doesn't work for build.log.gz. |
71 |
|
72 |
Anyway, I've had another thought, that since portage is flushing lines |
73 |
to the gzipped log fairly frequently, it's probably not getting the |
74 |
best compression ratio. So I went and tested recompressing some logs, |
75 |
and got a decent improvement: |
76 |
|
77 |
- nodejs-18.9.1: build.log.gz is 112KB, recompressed it's 68.9KB |
78 |
(38.5% savings). |
79 |
|
80 |
- qtwebengine-5.15.8_p20230112: build.log.gz is 1.44MB, recompressed |
81 |
it's 1.01MB (29.9% savings). |
82 |
|
83 |
- gtk+-3.24.37: build.log.gz is 157KB, recompressed it's 120KB |
84 |
(23.6% savings). |
85 |
|
86 |
So maybe I'm better off abandoning this feature, and setting something |
87 |
up to compress build logs after the fact. Then good ol' tail -f will |
88 |
work just fine. |
89 |
|
90 |
Thanks, cheers, |
91 |
Bryan |