# error in /etc/daily



## hazmat (Jun 21, 2002)

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.


----------



## hazmat (Jun 21, 2002)

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:


```
-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


```
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.


----------



## hazmat (Jun 21, 2002)

> _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.


----------



## hazmat (Jun 21, 2002)

Btw:


```
% 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
```


----------



## hazmat (Jun 21, 2002)

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.


----------



## hazmat (Jun 22, 2002)

Well it happened again.  In the daily output mail, and now also the weekly output mail.  Both end in the same thing:


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

or


```
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?


----------



## hazmat (Jun 27, 2002)

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.


----------



## hazmat (Jun 28, 2002)

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.


----------



## hazmat (Jun 28, 2002)

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.


----------

