Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#15269 - [lm_sensors] fancontrol usually fails to start up from /etc/rc.conf

Attached to Project: Arch Linux
Opened by Andrew Munkres (amunkres) - Friday, 26 June 2009, 06:03 GMT
Last edited by Eric Belanger (Snowman) - Tuesday, 29 September 2009, 07:29 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Eric Belanger (Snowman)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
When I run "/etc/rc.d/fancontrol start" manually, fancontrol will start. However, when putting "fancontrol" in the DAEMONS variable in /etc/rc.conf, it usually fails to start at startup time.

Additional info:
* package version(s)
lm_sensors 3.1.1-1
* config and/or log files etc.
See attached /etc/rc.conf and /etc/fancontrol.

Steps to reproduce:
Generate an /etc/fancontrol file (the program pwmconfig can do this), test running "/etc/rc.d/fancontrol start" to make sure it works, put "fancontrol" in the DAEMONS variable in /etc/rc.conf, reboot, and see if fancontrol starts up automatically.
This task depends upon

Closed by  Eric Belanger (Snowman)
Tuesday, 29 September 2009, 07:29 GMT
Reason for closing:  Fixed
Additional comments about closing:  fancontrol daemon script fixed in lm_sensors-3.1.1-2. It should now display [FAIL] when it fails.
Comment by Eric Belanger (Snowman) - Friday, 26 June 2009, 20:20 GMT
I don't have the hardware to test this (can't control my fans). You'll need to help me debugging it:
1- Can you confirm that it was working with lm_sensors 3.1.0-1 ?
2- In /etc/rc.d/fancontrol, replace
/usr/sbin/fancontrol >/dev/null 2>&1 &
by
/usr/sbin/fancontrol >/tmp/fancontroltest 2>&1 &
and reboot. If it fails, post the content of /tmp/fancontroltest here. Hopefully, there will be a useful error message.
3- When you run it manually, does it always start?
4- When you start it as daemon (rc.conf), you said "it usually fails". Does that mean that sometime it works and sometime it fails?
Comment by Andrew Munkres (amunkres) - Saturday, 27 June 2009, 01:00 GMT
1- It was not working with version 3.1.0-1. I first added "fancontrol" to DAEMONS on 2009-04-30, /var/log/pacman.log shows an upgrade from 3.1.0-1 to 3.1.1-1 on 2009-06-25, and the automatic startup was not working either before or after the upgrade.
2- See the attached file.
3- It has every time I've tried it so far.
4- It has sometimes started, but very seldom. (Maybe something like 1 time out of 30.)
Comment by Andrew Munkres (amunkres) - Saturday, 27 June 2009, 01:52 GMT
I think that part of the problem is that I had run the "sensors-detect" program and added the results to /etc/rc.local, including the loading of kernel modules and the running of "/usr/bin/sensors -s". Because /etc/rc.multi processes DAEMONS before it runs /etc/rc.local, this means that the modules weren't loaded at the time that it tried to start fancontrol.

I have now changed /etc/rc.local to run /etc/rc.d/fancontrol after setting up sensors, and that seems to work.

However, I tried commenting out all the lines of /etc/rc.local, putting the list of modules into the MODULES variable in /etc/rc.conf, and putting "sensors" (which runs "sensors -s") into DAEMONS immediately before "fancontrol". When it was that way, fancontrol still failed to start; in fact, it wouldn't even start manually when using that configuration. I don't understand why, because that configuration should do the same things that my /etc/rc.local file does.
Comment by Eric Belanger (Snowman) - Saturday, 27 June 2009, 02:31 GMT
> However, I tried commenting out all the lines of /etc/rc.local, putting the list of modules into the MODULES variable in /etc/rc.conf, and putting "sensors" > (which runs "sensors -s") into DAEMONS immediately before "fancontrol".

That should be the proper way to do it. What error messages are you getting (fancontroltest) ?
Comment by Andrew Munkres (amunkres) - Saturday, 27 June 2009, 05:34 GMT
The problem when loading modules from rc.conf was that the hwmon devices were numbered differently in sysfs. When the modules were loaded from rc.local, the hwmon devices were numbered this way:

[amunkres@ryokucha ~]$ ls -alt /sys/class/hwmon/
total 0
drwxr-xr-x 39 root root 0 2009-06-26 22:12 ..
lrwxrwxrwx 1 root root 0 2009-06-26 22:12 hwmon2 -> ../../devices/platform/coretemp.0/hwmon/hwmon2
lrwxrwxrwx 1 root root 0 2009-06-26 22:12 hwmon3 -> ../../devices/platform/coretemp.1/hwmon/hwmon3
lrwxrwxrwx 1 root root 0 2009-06-26 22:12 hwmon1 -> ../../devices/platform/w83627ehf.656/hwmon/hwmon1
drwxr-xr-x 2 root root 0 2009-06-26 22:12 .
lrwxrwxrwx 1 root root 0 2009-06-26 22:12 hwmon0 -> ../../devices/virtual/hwmon/hwmon0
[amunkres@ryokucha ~]$

When they were loaded from rc.local, the devices were numbered this way:

[amunkres@ryokucha ~]$ ls -alt /sys/class/hwmon/
total 0
drwxr-xr-x 39 root root 0 2009-06-26 22:02 ..
drwxr-xr-x 2 root root 0 2009-06-26 21:56 .
lrwxrwxrwx 1 root root 0 2009-06-26 21:56 hwmon0 -> ../../devices/platform/w83627ehf.656/hwmon/hwmon0
lrwxrwxrwx 1 root root 0 2009-06-26 21:56 hwmon1 -> ../../devices/platform/coretemp.0/hwmon/hwmon1
lrwxrwxrwx 1 root root 0 2009-06-26 21:56 hwmon2 -> ../../devices/platform/coretemp.1/hwmon/hwmon2
lrwxrwxrwx 1 root root 0 2009-06-26 21:56 hwmon3 -> ../../devices/virtual/hwmon/hwmon3
[amunkres@ryokucha ~]$

The /etc/fancontrol configuration file that pwmconfig generated was configured to use the hwmon1 device, which formerly was the real device "platform/w83627ehf.656", but now was the real device "platform/coretemp.0".

I reran pwmconfig to generate a new /etc/fancontrol file, and now fancontrol starts up correctly.

There still seems to be one problem: when fancontrol was unable to start up (due to the missing modules or the incorrect device number), it displayed "[DONE]" instead of "[FAIL]".

Loading...