On Wed 11th Aug, 2010 at 19:58, Scott Haneda seems to have written:
> Thanks for the answers, a few questions below...
> On Aug 11, 2010, at 7:14 PM, cfrees@... wrote:
>> On 10.4, I use this:
>> /usr/local/sbin/smartd -p /var/run/smartd.pid -l local3 -c \
>> in a StartupItem. (This usually means I couldn't make it work with launchd.)
> Ok, I should be able to manage that in launchd. I did try on the command line, just starting smartd with -l local3 as you have, but I was unable to get it to report anything to the log at all. I could use `logger` as follows:
> logger -p local3.debug "this is a test log"
> and that would send the line to system.log, but smartd would not. Perhaps it won't when started from the command line?
I wouldn't expect that to make a difference but setting -l local3 won't
have any effect unless local3 is directed somewhere in syslog.conf, I
> Does smartd have to fork in order for the logging to happen? I read in the man page that using -d for debug will halt the logging and send logging to stdout, but even stopping that and I was still not able to get log data to show up.
>> I use this with a customised log facility specified in syslog.conf:
>> local3.* /usr/local/var/log/smartd.log
>> which you obviously don't wish to do.
> Yes, ideally I would avoid that. However, in my tests, I did try that, along with the above steps, and only would the `logger` command work.
smartd is *very* quiet. For example, here's the current contents of my
Aug 12 02:01:19 CyfrifiadurCFR smartd: Device: /dev/disk0, SMART Usage Attribute: 194 Temperature_Celsius changed from 107 to 103\n
Aug 12 02:31:20 CyfrifiadurCFR smartd: Device: /dev/disk0, SMART Usage Attribute: 194 Temperature_Celsius changed from 103 to 105\n
Aug 12 03:01:19 CyfrifiadurCFR smartd: Device: /dev/disk0, SMART Usage Attribute: 194 Temperature_Celsius changed from 105 to 107\n
Aug 12 14:01:20 CyfrifiadurCFR smartd: Device: /dev/disk0, SMART Usage Attribute: 194 Temperature_Celsius changed from 107 to 106\n
Aug 12 14:31:19 CyfrifiadurCFR smartd: Device: /dev/disk0, SMART Usage Attribute: 194 Temperature_Celsius changed from 106 to 107\n
So it is very possible that there were simply no log messages during
the time you looked.
>> On the version of smartmontools I'm using (5.38), the man page
>> specifies the values as one of local0-7. On my machine, most of these
>> are not directed anywhere in particular by syslog.conf by default
>> certainly not to system.log. So no argument passed to smartd with -l
>> would do what you want here.
> What about the daemon log facility? Does OS X handle that at all?
I think so but I assumed from the man page that smartmontools would
only accept a value of local0-7 for facility. However, maybe that's not
right. Or maybe it is different in 5.39.1.
>> However, you would still get messages of sufficient importance logged to
>> system.log, I think, even though you will not get the routine status
> It is strange, I was not able to get a single line to ever log. I will try your start command.
You will see messages of sufficient importance in the system log only
if things are going wrong. I saw no messages from smartd in system.log
(only the routine ones in smartd.log) for years. Only when my disk was
failing did I see messages logged to system.log.
> I was hoping there would be a way to modify the source to allow one of the logging facilities to be more friendly to OS X. I just started looking through it to see how much of a mess I would make of things to go that route.
>> Incidentally and not that my view matters, it strikes me as odd to have
>> a policy of non-modification with respect to configuration files but to
>> be quite happy directing the output from MacPorts software to
>> system.log. I would personally be more bothered about keeping the
>> latter distinct than the former. (But then that's why I use the setup
>> described, I suppose.)
> This is sort of a unique case. My my decision than their policy. I suspect if I were to re-read the layout guidelines, it would be suggested that the logging data end up in MacPorts prefix under var/log as well. However, that is still not going to stop me from needing to alter syslog.conf.
> The main idea behind not modifying system files is that Apple can and does change them during software updates. The more self contained things are, the less chance they have of breaking. For example, Apache logs within MacPorts prefix. My Pure-FTPd port logs within the prefix as well.
I know that's the idea but sometimes it feels more like working against
the system rather than with it!
> I am just trying to find the best way to solve this, which very well may mean altering the portfile and submitting the changes to MacPorts. First I have to get it to actually work in test though.
> Thanks for the help.
You're welcome. Maybe one of the smartmontools experts will have a
better idea - I am certainly not in that category!