shimi <[email protected]> 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 | [email protected] _______________________________________________ Linux-il mailing list [email protected] http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
