extra bytes in zip archive when used with logrotate

[Oleg Goldshmidt]

shimi <linux-il at shimi.net> writes:

> * Aliases existing on some user and not on the other

No, I used full paths for all executables, as /bin/cat and /usr/bin/zip.

> * Running from shell vs. not from shell (related to above two)

This reminds me of my other recent discovery (/dev/stderr, pipes, and
crontab), but there the problem was permisions and here I ran
everything as root. Also, I ran logrotate from the shell, too, albeit
normally it would run from cron, of course.

> * being attached to a pty / not being (where does output go?)

I ran everything from the same shell/session/pty. 

Well, logrotate calls pipe() and dup() (on 0 and 1, IIRC), essentially
redirecting internally, but the necessary stuff does get to the right
place. It was zip that caused the problem, and it was its output that
screwed things up (given that -q fixed it). But why did it depend on
the pipe? I'll try to play with it some more.

> * a default of a tool may have changed, did you upgrade your system
>   lately?

Yes, first time I ran it on CentOS 6.2, but zip is very stable and I
doubt -q was ever the default. In principle, anything is possible, but
if the default behaviour of zip changed in such a way then I imagine
all sorts of things could and would blow up in smoke all over the
planet, eh?

> * stdout / stderr redirections on various invocations

See above - possible...

> Finally, strace is your friend, you can see how a process was called
> if you log strace output.

Still in the future...

> Also, this could be nonsense, but, I note that your logrotate is
> with -v - I'm too tired to think, but maybe the logrotate verbosity
> goes into the mix...

No, with and without -v was the same. I actually wrote that in
parentheses in my OP but then deleted for brevity.

Thanks again,

-- 
Oleg Goldshmidt | pub at goldshmidt.org