I'm noticing that logrotate's default configuration for rotating /var/ log/secure and /var/log/messages partially fails if root's shell is set to /bin/tcsh (via chsh). (Running on CentOS 4.4; logrotate-3.7.1-5.RHEL4).
What seems to be happening is that the logrotate.d/syslog postrotate command runs: /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
Under bash, this redirects stderr to /dev/null. Under tcsh, this produces the error: cat: 2: No such file or directory
What happens in this scenario is that the log gets rotated, but syslogd does not receive the SIGHUP, so nothing gets logged, at all. (i.e. secure and messages are 0 bytes until syslog is kicked).
I'm just going to set the default shell for root back to bash, but I wanted to ask the list if there is any general "rule of thumb" that root's shell should be bash?
best, Jeff
On 11/03/07, Jeff Potter jpotter-centos@codepuppy.com wrote:
I'm noticing that logrotate's default configuration for rotating /var/ log/secure and /var/log/messages partially fails if root's shell is set to /bin/tcsh (via chsh). (Running on CentOS 4.4; logrotate-3.7.1-5.RHEL4).
What seems to be happening is that the logrotate.d/syslog postrotate command runs: /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
Under bash, this redirects stderr to /dev/null. Under tcsh, this produces the error: cat: 2: No such file or directory
What happens in this scenario is that the log gets rotated, but syslogd does not receive the SIGHUP, so nothing gets logged, at all. (i.e. secure and messages are 0 bytes until syslog is kicked).
I'm just going to set the default shell for root back to bash, but I wanted to ask the list if there is any general "rule of thumb" that root's shell should be bash?
Across most Unixes I think it's a given that root's shell is just 'sh', either /bin/sh or /sbin/sh. On Solaris a commonly warned against mistake was to either change root's shell to a dynamically linked shell which wouldn't work properly in single-user because of linked libraries residing on unmounted partition (only / was mounted in single user mode IIRC) or because it was /usr/local/bin/bash, again with /usr/ not residing in a directory under / .
You can set SHELL=/bin/bash in crontabs to override a user's default shell. See "man 5 crontab" for details.
Your error is being caused by limitations in csh's handling of standard file descriptors, explained here:
http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/
http://www.google.co.uk/search?hl=en&q=csh+stderr&btnG=Google+Search...
Will.
On Sun, Mar 11, 2007 at 09:17:38AM -0400, Jeff Potter wrote:
I'm just going to set the default shell for root back to bash, but I wanted to ask the list if there is any general "rule of thumb" that root's shell should be bash?
Root's shell should be bourne shell compliant. Setting it to tcsh is shooting yourself in the foot. If you want to do administrative tasks and use tcsh, use sudo for the commands that need root access.
-
Jeff Potter -
Matthew Miller -
Will McDonald