Discussion:
[gentoo-user] Disable fcron logging
(too old to reply)
Alex Schuster
2010-08-21 13:30:02 UTC
Permalink
Hi there!

I want to monitor the power status of my hard drives, so I wrote a little
script that gives me this output:

sda: standby
sdb: standby
sdc: active/idle 32°C
sdd: active/idle 37°C

This script is called every minute via an fcron entry, output goes into a
log file, and I use the file monitor plasmoid to watch this log file in
KDE.

It's working fine, but also monitor my syslog in another file monitor
plamoid, and now I get lots of these entries:

Aug 21 14:21:06 [fcron] pam_unix(fcron:session): session opened for user root by (uid=0)
Aug 21 14:21:06 [fcron] Job /usr/local/sbin/hdstate >> /var/log/hdstate started for user root (pid 24483)
Aug 21 14:21:08 [fcron] Job /usr/local/sbin/hdstate >> /var/log/hdstate completed
Aug 21 14:21:08 [fcron] pam_unix(fcron:session): session closed for user root

There is a nolog option for fcrontab, but I still get this output every
minute:

Aug 21 15:10:06 [fcron] pam_unix(fcron:session): session opened for user root by (uid=0)
Aug 21 15:10:08 [fcron] pam_unix(fcron:session): session closed for user root

Hmmm... could it be that these entries do not come from fcron itself, but
from PAM? Do I need to look there so suppress them? And if so, would this
make sense? I want to suppress only these specific logs, not other stuff
that might be interesting.

Any ideas? It's nothing important, but maybe there's a simple solution,
and I like to learn. Don't knwo much about this PAM stuff yet.
Maybe I'll just start a background job for that instead of using fcron.

Wonko
Alan McKinnon
2010-08-21 13:50:01 UTC
Permalink
Apparently, though unproven, at 15:25 on Saturday 21 August 2010, Alex
Post by Alex Schuster
Hi there!
I want to monitor the power status of my hard drives, so I wrote a little
sda: standby
sdb: standby
sdc: active/idle 32°C
sdd: active/idle 37°C
This script is called every minute via an fcron entry, output goes into a
log file, and I use the file monitor plasmoid to watch this log file in
KDE.
It's working fine, but also monitor my syslog in another file monitor
Aug 21 14:21:06 [fcron] pam_unix(fcron:session): session opened for user
root by (uid=0) Aug 21 14:21:06 [fcron] Job /usr/local/sbin/hdstate >>
/var/log/hdstate started for user root (pid 24483) Aug 21 14:21:08 [fcron]
Job /usr/local/sbin/hdstate >> /var/log/hdstate completed Aug 21 14:21:08
[fcron] pam_unix(fcron:session): session closed for user root
There is a nolog option for fcrontab, but I still get this output every
That will tell fcron not to log stuff.
It will not tell other apps to not stuff
Post by Alex Schuster
Aug 21 15:10:06 [fcron] pam_unix(fcron:session): session opened for user
root by (uid=0) Aug 21 15:10:08 [fcron] pam_unix(fcron:session): session
closed for user root
Hmmm... could it be that these entries do not come from fcron itself, but
from PAM?
Yes.

Configure your syslogger to devnull these specific entries.
All three common sysloggers (syslogd,syslog-ng,rsyslog) all come with
extensive documentation on how to do this.
--
alan dot mckinnon at gmail dot com
Alex Schuster
2010-08-23 22:20:02 UTC
Permalink
Post by Alan McKinnon
Apparently, though unproven, at 15:25 on Saturday 21 August 2010, Alex
Post by Alex Schuster
There is a nolog option for fcrontab, but I still get this output
That will tell fcron not to log stuff.
It will not tell other apps to not stuff
Right. But I did not know that there are more things involved than cron
itself and the command I am calling. This PAM stuff is new to me, but
maybe I just never noticed it before in my logs. It's no problem when it's
not coming every minute.
Post by Alan McKinnon
Post by Alex Schuster
Aug 21 15:10:06 [fcron] pam_unix(fcron:session): session opened for
user root by (uid=0) Aug 21 15:10:08 [fcron]
pam_unix(fcron:session): session closed for user root
Hmmm... could it be that these entries do not come from fcron itself,
but from PAM?
Yes.
Configure your syslogger to devnull these specific entries.
All three common sysloggers (syslogd,syslog-ng,rsyslog) all come with
extensive documentation on how to do this.
Hmm, okay. I think there is no perfect solution. When I disable logging of
this PAM stuff, I can only disable it completely, but what if I want to
keep the logging from other jobs that are not run that often? Although for
this case I can use the direct logging of fcron (without nolog), so this
is quite academic. Can anybody still follow me? But thanks for the
clarification.

Meanwhile, I have the script running in /etc/conf.d/local.start, so I have
no syslog output at all and I also can have more updates than only once
per minute.

Wonko
Alan McKinnon
2010-08-24 07:00:02 UTC
Permalink
Apparently, though unproven, at 00:12 on Tuesday 24 August 2010, Alex Schuster
Post by Alex Schuster
Post by Alan McKinnon
Configure your syslogger to devnull these specific entries.
All three common sysloggers (syslogd,syslog-ng,rsyslog) all come with
extensive documentation on how to do this.
Hmm, okay. I think there is no perfect solution. When I disable logging of
this PAM stuff, I can only disable it completely, but what if I want to
keep the logging from other jobs that are not run that often? Although for
this case I can use the direct logging of fcron (without nolog), so this
is quite academic. Can anybody still follow me? But thanks for the
clarification.
I use syslog-ng and that allows you to write a custom rule looking for the app
that generated the log "[fcron]" and a string in the log entry
"pam_unix(fcron:session)". You can then filter it out.

However you do it, the solution is quite fragile and very specific to your
setup. A general solution that works everywhere will be difficult to form.
--
alan dot mckinnon at gmail dot com
Stroller
2010-08-21 19:30:02 UTC
Permalink
Post by Alex Schuster
...
I want to monitor the power status of my hard drives, so I wrote a little
sda: standby
sdb: standby
sdc: active/idle 32°C
sdd: active/idle 37°C
This script is called every minute via an fcron entry, output goes into a
log file, and I use the file monitor plasmoid to watch this log file in
KDE.
It's working fine, but also monitor my syslog in another file monitor
Aug 21 14:21:06 [fcron] pam_unix(fcron:session): session opened for user root by (uid=0)
Aug 21 14:21:06 [fcron] Job /usr/local/sbin/hdstate >> /var/log/
hdstate started for user root (pid 24483)
Aug 21 14:21:08 [fcron] Job /usr/local/sbin/hdstate >> /var/log/
hdstate completed
Aug 21 14:21:08 [fcron] pam_unix(fcron:session): session closed for user root
#!/bin/bash
while true
do
for drive in a b c d
do
/usr/sbin/smartctl /dev/sd$drive --whatever >> /var/log/hdstate
done
sleep 60
done


I would personally update more often than this, and my concern would
be that if the process fails then your plasmoid isn't showing the
correct data.

I presume this is the same with your current setup: if cron dies then
the current temperature will not be read to file, and the plasmoid
will continue reading the last lines in /var/log/hdstate - the drive
can overheat without you knowing about it.

So I would expect there to be a better "plasmid" for this task. I'm
completely unfamiliar with plasmids, but what you really want is a
plasmid that itself runs a script and displays the stdout on your
screen. That way if there's no data, or an error, then _you see that
in the plasmid_, instead of silently ignoring it (as you may be at
present).

The easiest (but dumb) way to handle this is to add the date to your
plasmid's display so that at least you can see that something's wrong
if it doesn't match the clock. A better way is not to have to watch a
status monitor at all, and just have a script running that emails you
if the temperature is above a specified range.

Stroller.
Alex Schuster
2010-08-22 10:30:02 UTC
Permalink
Post by Stroller
Post by Alex Schuster
...
I want to monitor the power status of my hard drives, so I wrote a little
sda: standby
sdb: standby
sdc: active/idle 32°C
sdd: active/idle 37°C
This script is called every minute via an fcron entry, output goes
into a log file, and I use the file monitor plasmoid to watch this log
file in KDE.
It's working fine, but also monitor my syslog in another file
Aug 21 14:21:06 [fcron] pam_unix(fcron:session): session opened for
user root by (uid=0)
Aug 21 14:21:06 [fcron] Job /usr/local/sbin/hdstate >> /var/log/
hdstate started for user root (pid 24483)
Aug 21 14:21:08 [fcron] Job /usr/local/sbin/hdstate >> /var/log/
hdstate completed
Aug 21 14:21:08 [fcron] pam_unix(fcron:session): session closed for user root
#!/bin/bash
while true
do
for drive in a b c d
do
/usr/sbin/smartctl /dev/sd$drive --whatever >> /var/log/hdstate
done
sleep 60
done
I use hdparm and hddtemp:

for hd in sda sdb sdc sdd
do
str=$( /sbin/hdparm -C /dev/$hd )
state=${str##*is: }
if [[ $state == active/idle ]] && [[ $hd =~ sd[c] ]]
then
temp=$( /usr/sbin/hddtemp -q /dev/$hd )
temp=${temp% or *}
temp=${temp##* }
else
temp=
fi
echo "$hd: $state $temp"
done

Unfortunately, reading the temperature makes a drive in standby spin up,
and prevents automatic spindown after a while of idle time. So now I ask
for the temperature only on my system drive, the others should sleep most
of the time anyway.
Post by Stroller
I would personally update more often than this, and my concern would
be that if the process fails then your plasmoid isn't showing the
correct data.
I presume this is the same with your current setup: if cron dies then
the current temperature will not be read to file, and the plasmoid
will continue reading the last lines in /var/log/hdstate - the drive
can overheat without you knowing about it.
Nah, it's really not that important for me. I show the temperature just
for the fun of it, and for extreme temperatures I have smartd running, see
below.
I'm more interested in the active/standby state. I just added two old
additonal IDE drives for additional backups, and I want them to be silent
most of the time. So I wrote a little script to show the status so I see
when they spin up again (and they do this sometimes), and used fcron to
get the data into a log file that the plasmoids shows.

The problem with cron is that I get those cron logs I do not like, and
that the update time of 60 seconds is a little long. Running the script in
a loop, started in .kde4/Autostart, would be better, but as a user I have
no permission to call hdparm or hdtemp. I do not want to be part of the
disk group, and when using sudo I would get the logs by sudo I wanted to
avoid. So now I SUID'ed hdparm and hddtemp, changed the group to wheel and
disabled execution for others. cron problem not solved, but workarounded.
Post by Stroller
So I would expect there to be a better "plasmid" for this task. I'm
completely unfamiliar with plasmids, but what you really want is a
plasmid that itself runs a script and displays the stdout on your
screen. That way if there's no data, or an error, then _you see that
in the plasmid_, instead of silently ignoring it (as you may be at
present).
The easiest (but dumb) way to handle this is to add the date to your
plasmid's display so that at least you can see that something's wrong
if it doesn't match the clock. A better way is not to have to watch a
status monitor at all, and just have a script running that emails you
if the temperature is above a specified range.
I have smartd running, which should send me mails about such things. For
each drive, I have a line like this in /etc/smartd.conf:

/dev/sdc -a -n standby -o on -S on -W 5,40,45 \
-s (S/../.././12|L/../../06/06) -m ***@wonkology.org

This does some regular health checks on the drive, when it is not in
standby mode. Temperature changes of more than 5 degrees and temperatures
of 40 degrees or more are logged. I will receive an email when the
temperature reaches 45 degrees, or when it reaches a new maximum. The
maximum values are preserved across boot cycles (option -S). Every day at
12:00, a short self test is scheduled, and a long self test each sunday on
06:00.

Wonko
Stroller
2010-08-22 19:10:01 UTC
Permalink
Post by Alex Schuster
Post by Stroller
#!/bin/bash
while true
do
for drive in a b c d
do
/usr/sbin/smartctl /dev/sd$drive --whatever >> /var/log/hdstate
done
sleep 60
done
for hd in sda sdb sdc sdd
do
...
echo "$hd: $state $temp"
done
The script with which you reply is missing the sleep 60 loop.
Post by Alex Schuster
...
The problem with cron is that I get those cron logs I do not like, and
that the update time of 60 seconds is a little long. Running the script in
a loop, started in .kde4/Autostart, would be better, but as a user I have
no permission to call hdparm or hdtemp. I do not want to be part of the
disk group, and when using sudo I would get the logs by sudo I
wanted to
avoid. So now I SUID'ed hdparm and hddtemp, changed the group to wheel and
disabled execution for others. cron problem not solved, but
workarounded.
Running a script which contains `while true ... sleep 60` will cause
only a single logging action. You can run it as root at startup using /
etc/conf.d/local.start and have the file world readable.

Stroller.
Stroller
2010-08-22 20:00:02 UTC
Permalink
Post by Stroller
Post by Alex Schuster
Post by Stroller
#!/bin/bash
while true
do
for drive in a b c d
do
/usr/sbin/smartctl /dev/sd$drive --whatever >> /var/log/hdstate
done
sleep 60
done
for hd in sda sdb sdc sdd
do
...
echo "$hd: $state $temp"
done
The script with which you reply is missing the sleep 60 loop.
Post by Alex Schuster
...
The problem with cron is that I get those cron logs I do not like, and
that the update time of 60 seconds is a little long. Running the script in
a loop, started in .kde4/Autostart, would be better, but as a user I have
no permission to call hdparm or hdtemp. I do not want to be part of the
disk group, and when using sudo I would get the logs by sudo I wanted to
avoid. So now I SUID'ed hdparm and hddtemp, changed the group to wheel and
disabled execution for others. cron problem not solved, but
workarounded.
Running a script which contains `while true ... sleep 60` will cause
only a single logging action. You can run it as root at startup
using /etc/conf.d/local.start and have the file world readable.
Sorry, this wasn't very clear:

If your script contains `while true ... sleep 60` then you'll only
need to run it once.

Stroller.
Alex Schuster
2010-08-22 21:50:02 UTC
Permalink
Post by Stroller
The script with which you reply is missing the sleep 60 loop.
No, it's only the script that outputs the drive's state. It's called by
~/.kde4/Autostart/hdstate:

#!/bin/bash

while :
do
/usr/local/sbin/hdstate >> ~/log/hdstate.log
sleep 10
done
Post by Stroller
Running a script which contains `while true ... sleep 60` will cause
only a single logging action. You can run it as root at startup using /
etc/conf.d/local.start and have the file world readable.
Yeah, local.start woudl also be a good idea, without the need to setuid
things. Maybe I'll change this.

BTW, my two additional drives spin up when I log into KDE. Weird, they are
not even mounted.

Wonko
Mick
2010-08-22 22:30:02 UTC
Permalink
Post by Alex Schuster
Post by Stroller
The script with which you reply is missing the sleep 60 loop.
No, it's only the script that outputs the drive's state. It's called by
#!/bin/bash
do
/usr/local/sbin/hdstate >> ~/log/hdstate.log
sleep 10
done
Post by Stroller
Running a script which contains `while true ... sleep 60` will cause
only a single logging action. You can run it as root at startup using /
etc/conf.d/local.start and have the file world readable.
Yeah, local.start woudl also be a good idea, without the need to setuid
things. Maybe I'll change this.
BTW, my two additional drives spin up when I log into KDE. Weird, they are
not even mounted.
From KDE-4.4.4 the start up interferes with the hard drives:

http://thread.gmane.org/gmane.linux.gentoo.user/232044

I don't why but it does, messes up any settings that hdparm may have set up
and p*sses me off. o_O

As soon as KDE starts up (even when waking up from suspend to ram) it resets
the drives. I haven't found a way of telling it how to behave (i.e. by
respecting existing settings in hdparm).
--
Regards,
Mick
Alex Schuster
2010-08-24 13:40:04 UTC
Permalink
Post by Mick
Post by Alex Schuster
BTW, my two additional drives spin up when I log into KDE. Weird,
they are not even mounted.
http://thread.gmane.org/gmane.linux.gentoo.user/232044
I don't why but it does, messes up any settings that hdparm may have
set up and p*sses me off. o_O
As soon as KDE starts up (even when waking up from suspend to ram) it
resets the drives. I haven't found a way of telling it how to behave
(i.e. by respecting existing settings in hdparm).
Argh, that's annoying. Thanks for the information. O well, first I
setuid'ed hdparm to make it work as a user, then I reverted that back as I
started it in /etc/init.d/local, and now I'm again setuid'ing it so I can
set the settings from /etc/conf.d/hdparm in ~/.kde4/Autostart/.

I filed a bug: https://bugs.kde.org/show_bug.cgi?id=248905
You might want to vote for it so it gets some attention and will hopefully
be fixed soon.

Wonko
Alex Schuster
2010-08-25 10:00:02 UTC
Permalink
Post by Alex Schuster
Post by Mick
http://thread.gmane.org/gmane.linux.gentoo.user/232044
I don't why but it does, messes up any settings that hdparm may have
set up and p*sses me off. o_O
As soon as KDE starts up (even when waking up from suspend to ram) it
resets the drives. I haven't found a way of telling it how to behave
(i.e. by respecting existing settings in hdparm).
Argh, that's annoying. Thanks for the information. O well, first I
setuid'ed hdparm to make it work as a user, then I reverted that back
as I started it in /etc/init.d/local, and now I'm again setuid'ing it
so I can set the settings from /etc/conf.d/hdparm in
~/.kde4/Autostart/.
I filed a bug: https://bugs.kde.org/show_bug.cgi?id=248905
You might want to vote for it so it gets some attention and will
hopefully be fixed soon.
They say it's probably specific to Gentoo, so I filed this bug:
http://bugs.gentoo.org/show_bug.cgi?id=334393

Wonko
Mick
2010-08-25 19:20:02 UTC
Permalink
Post by Alex Schuster
Post by Alex Schuster
Post by Mick
http://thread.gmane.org/gmane.linux.gentoo.user/232044
I don't why but it does, messes up any settings that hdparm may have
set up and p*sses me off. o_O
As soon as KDE starts up (even when waking up from suspend to ram) it
resets the drives. I haven't found a way of telling it how to behave
(i.e. by respecting existing settings in hdparm).
Argh, that's annoying. Thanks for the information. O well, first I
setuid'ed hdparm to make it work as a user, then I reverted that back
as I started it in /etc/init.d/local, and now I'm again setuid'ing it
so I can set the settings from /etc/conf.d/hdparm in
~/.kde4/Autostart/.
I filed a bug: https://bugs.kde.org/show_bug.cgi?id=248905
You might want to vote for it so it gets some attention and will
hopefully be fixed soon.
http://bugs.gentoo.org/show_bug.cgi?id=334393
Wonko
Thank you! I topped it up. ;-)
--
Regards,
Mick
Mick
2010-08-30 16:40:04 UTC
Permalink
Post by Alex Schuster
Post by Mick
Post by Alex Schuster
BTW, my two additional drives spin up when I log into KDE. Weird,
they are not even mounted.
http://thread.gmane.org/gmane.linux.gentoo.user/232044
I don't why but it does, messes up any settings that hdparm may have
set up and p*sses me off.  o_O
As soon as KDE starts up (even when waking up from suspend to ram) it
resets the drives.  I haven't found a way of telling it how to behave
(i.e. by respecting existing settings in hdparm).
Argh, that's annoying. Thanks for the information. O well, first I
setuid'ed hdparm to make it work as a user, then I reverted that back as I
started it in /etc/init.d/local, and now I'm again setuid'ing it so I can
set the settings from /etc/conf.d/hdparm in ~/.kde4/Autostart/.
I filed a bug: https://bugs.kde.org/show_bug.cgi?id=248905
You might want to vote for it so it gets some attention and will hopefully
be fixed soon.
Thanks Wonko,

As reported on https://bugs.gentoo.org/show_bug.cgi?id=334393 the workaround of:

touch /etc/pm/power.d/harddrive

stops KDE4.4.4/5 from messing up the existing hdparm settings (at
least as far as acoustic management is concerned). At least now I
don't have to listen this Seagate sata rattling all day! :-)
--
Regards,
Mick
Stroller
2010-08-23 18:30:02 UTC
Permalink
Post by Alex Schuster
Post by Stroller
The script with which you reply is missing the sleep 60 loop.
No, it's only the script that outputs the drive's state. It's called by
#!/bin/bash
do
/usr/local/sbin/hdstate >> ~/log/hdstate.log
sleep 10
done
You wrote to the list telling us that you were running a script from
cron every minute, and that this was causing your log file to fill up
with messages from cron.

That is what I replied to.

Please do not move the goalposts halfway through the thread, and make
it about something else unrelated. That is the perfect way to annoy
people who are trying to help you.


Stroller.
Alex Schuster
2010-08-23 21:40:02 UTC
Permalink
Post by Stroller
Post by Alex Schuster
Post by Stroller
The script with which you reply is missing the sleep 60 loop.
No, it's only the script that outputs the drive's state. It's called
#!/bin/bash
do
/usr/local/sbin/hdstate >> ~/log/hdstate.log
sleep 10
done
You wrote to the list telling us that you were running a script from
cron every minute, and that this was causing your log file to fill up
with messages from cron.
That is what I replied to.
Yes, I know. You had the good idea of simply putting the script into a
loop, and I actually followed your advice by now. When I posted my first
script in response to yours, I just wanted to show how I got the
relevant information in a more convenient format, using hdparm and
hddtemp, than using the direct output of smartctl. Just in case someone
else also likes this. Of yourse the outer loop was missing, but I did
not bother to add this trivial addition just for the posting here. It's
just the script I was already using in cron. And later in the posting I
mentioned that the script itself should be run in a loop instead of
cron, also because I could decrease the update interval.

Sorry, I probably should have made clear that the original question was
sort of solved.
Post by Stroller
Please do not move the goalposts halfway through the thread, and make
it about something else unrelated. That is the perfect way to annoy
people who are trying to help you.
I'm sorry about this, I did not mean to annoy anyone. But I still do not
really seewhat the problem is. You had the idea to do this without cron,
and so I did. Well, I forgot a 'thank you' for the loop idea, this is
true. Sorry again. Your ideas were appreciated as always.

Wonko
Loading...