error in /etc/daily

hazmat

Rusher of Din
I finally redirected root mail from /dev/null to my account, since I now got Postfix working (not totally related). So I get a message that I traced down to /etc/daily:

Rotating log files: system.logUnknown option: 1

The line from daily is:

if [ -f /var/run/syslog.pid ]; then kill -HUP $(cat /var/run/syslog.pid | head -1); fi

I'm not sure which way I should attack this. Simply take out the -1 or change the head option?

Thanks.
 
My /etc/daily looks just like yours. I never touched it. The file hasn't been modified since Sep 2 2001. /usr/bin/gzip exists, and I do have eight copies of system.log* in /var/log, but it seems that they haven't been logging. Here are the files:

Code:
-rw-r-----    1 root    wheel        0 Jun 21 03:15 system.log
-rw-r-----    1 root    wheel       33 Jun 20 03:15 system.log.0.gz
-rw-r-----    1 root    wheel       33 Jun 19 03:15 system.log.1.gz
-rw-r-----    1 root    wheel       33 Jun 18 03:15 system.log.2.gz
-rw-r-----    1 root    wheel     2526 Jun 18 03:15 system.log.3.gz
-rw-r-----    1 root    wheel       33 Jun 16 03:15 system.log.4.gz
-rw-r-----    1 root    wheel     4956 Jun 16 03:15 system.log.5.gz
-rw-r-----    1 root    wheel     2129 Jun 15 03:15 system.log.6.gz
-rw-r-----    1 root    wheel       33 Jun 13 03:15 system.log.7.gz

I looked in system.log.3 and the interesting stuff at the end is

Code:
Jun 18 03:15:00 e-this CRON[370]: (root) CMD (sh /etc/daily^I2>&1 | tee /var/log/daily.out^I| mail -s "`hostname` daily output"   root) 
Jun 18 03:15:01 e-this lookupd[208]: _lookup_all(getfsent) failed
Jun 18 03:15:01 e-this sendmail[385]: NOQUEUE: SYSERR(root): /etc/mail/sendmail.cf: line 81: fileclass: cannot open '/etc/mail/local-host-names': Group writable directory

Not sure if it Postfix has to do with this, but I installed it on June 19. :-/ I didn't actually physically build Postfix from source, I used http://www.hmug.org/HowTos/postfix.html as well as http://www.stepwise.com/Articles/Workbench/eart.1.3.1.html . But as I said, that was on June 19. Looks like it is version 20010228-pl08.

Thanks for the help.
 
Originally posted by testuser
Hmmm... your syslogd daemon should be running in order to have proper system logging. To see if it is running:
ps `cat /var/run/syslog.pid`

It is running.


I doubt the Postfix installation has anything to do with this current problem. You might also want to run Disk First Aid just to make sure that your hard drive is OK.

I'll try that tonight.


I tried to install Postfix a few days ago. I looked at that installation script, but decided is was a little old. I installed updated versions of the Berkeley db (4.0), and pcre(3.7), and tried to install the current 1.1.11 version of Postfix when it choked at the "make" (a problem with "ld"). Maybe I'll give it a try with last year's final version, or just do it with the script. Are you running OS X 10.1.4 or 10.1.5? ... and postfix shows up as a running process?

I'm running 10.1.5. Postfix is running just fine. All the notes between those two sites totally got it up and running. I have tried Sendmail, Exim, and Postfix, and Postfix is the only one I could get to run perfecty for sending and receiving local and remote mail with mutt. I know what you mean about older versions, but if it runs, it's worth a lot to me. :)

I'm gonna try rebooting and see what happens.
 
Btw:

Code:
% ps auwx | grep postfix
root    13077   0.0  0.0     1720    372  ??  Ss     0:02.37 /usr/libexec/postfix/master
postfix 13079   0.0  0.1     2520    476  ??  S      0:01.73 qmgr -l -t fifo -u
postfix 14292   0.0  0.0     2352    424  ??  S      0:00.02 pickup -l -t fifo
 
Huh. I rebooted and it seems to be logging just fine again. I wonder what happened to make it stop.

Thanks for the the help, testuser.

Btw, Postfix survived the reboot and it working great.
 
Well it happened again. In the daily output mail, and now also the weekly output mail. Both end in the same thing:

Code:
Rotating log files: system.logUnknown option: 1

or

Code:
Rotating log files: ftp.log lookupd.log lpr.log mail.log netinfo.logUnknown option: 1

and then give the output of head without options. From the command line I get the same thing, -1 is not a valid option. And then they all stop logging. WTF?
 
Okay, I fixed it. Apparently something perl-related replaced /usr/bin/head with something else. What I have no idea. perl is v5.6.0, which I guess is the default install? So anyway, I got the default Darwin version of head from a friend, and everything is fine now.
 
Exactly. And the weirdest part was having to ask a friend to give me head. :)

I would guess the replacement happened when I installed Postfix. Maybe not. I usually install things manually from source, but this time let it do it automatically. Learned my lesson. :) But someone said that the problem was due to HFS+'s case-insenitivity. That's something I don't understand, though, since from the Terminal, things ARE case-sensitive.
 
Check this out: http://developer.apple.com/internet/macosx/perl.html .

In particular:


A Troubleshooting Note

One of the major causes of confusion when installing Perl modules or other new software on a Mac OS X system is an idiosyncrasy of the system's HFS+ file system--it doesn't distinguish by case. On a traditional Unix system, two different files whose names differ only by case--for example, CGI and cgi--can exist in the same directory. The HFS+ file system would regard those two as the same file.

This can result in difficulties when installing a software package that was designed for a case-sensitive system. For example, libwww-perl by default installs an HTTP script called HEAD, which is used to make an HTTP HEAD request. If this is installed to /usr/bin, it can overwrite the BSD built-in /usr/bin/head command, used for reading the beginnings of files. To prevent this kind of collision when using HFS+, it's necessary to configure CPAN.pm to install modules to a private directory. It's also a good idea to make sure there are no files sharing names before you install a new package.
 
Back
Top