Ticket #2319 (closed defect: fixed)

Opened 5 months ago

Last modified 4 months ago

many fancontrol process

Reported by: ticket Assigned to: khali
Priority: minor Milestone: 3.0.3
Component: fancontrol Version: 3.0.1
Keywords: Cc: higuita@gmx.net

Description (Last modified by khali)

I already noted that for some reason fancontrol is swapping new process in random times: 

# ps xua|grep fan[c]

root      4387  0.0  0.0  19940   868 pts/7    S+   03:02   0:00 /bin/bash /usr/local/sbin/fancontrol
root      4388  0.0  0.0  19940   868 pts/7    S+   03:02   0:00 /bin/bash /usr/local/sbin/fancontrol
root      6320  0.0  0.0  19952   880 pts/7    S+   03:20   0:00 /bin/bash /usr/local/sbin/fancontrol
root      9298  0.0  0.0  19972   900 pts/7    S+   03:56   0:00 /bin/bash /usr/local/sbin/fancontrol
root      9300  0.0  0.0  19972   900 pts/7    S+   03:56   0:00 /bin/bash /usr/local/sbin/fancontrol
root      9416  0.0  0.0  19972   900 pts/7    S+   03:58   0:00 /bin/bash /usr/local/sbin/fancontrol
root      9417  0.0  0.0  19972   900 pts/7    S+   03:58   0:00 /bin/bash /usr/local/sbin/fancontrol
root     10514  0.0  0.0  19984   912 pts/7    S+   04:15   0:00 /bin/bash /usr/local/sbin/fancontrol
root     22377  0.0  0.0  19996  2036 pts/7    S+   Apr30   0:02 /bin/bash /usr/local/sbin/fancontrol
root     27040  0.0  0.0  19824   752 pts/7    S+   00:29   0:00 /bin/bash /usr/local/sbin/fancontrol
root     28806  0.0  0.0  19840   768 pts/7    S+   00:54   0:00 /bin/bash /usr/local/sbin/fancontrol
root     28807  0.0  0.0  19840   768 pts/7    S+   00:54   0:00 /bin/bash /usr/local/sbin/fancontrol
root     29338  0.0  0.0  19844   772 pts/7    S+   01:01   0:00 /bin/bash /usr/local/sbin/fancontrol
root     29339  0.0  0.0  19844   772 pts/7    S+   01:01   0:00 /bin/bash /usr/local/sbin/fancontrol

i usally start and send to background the fancontrol, but to try to seen what happends, i started in a shell and there is the result output: 

 /usr/local/sbin/fancontrol
Loading configuration from /etc/fancontrol ...

Common settings:
  INTERVAL=10

Settings for /sys/devices/platform/w83627hf.656/pwm2:
  Depends on /sys/devices/platform/w83627hf.656/temp2_input
  Controls /sys/devices/platform/w83627hf.656/fan2_input
  MINTEMP=26
  MAXTEMP=45
  MINSTART=100
  MINSTOP=95
  MINPWM=0
  MAXPWM=255

Settings for /sys/devices/platform/w83627hf.656/pwm1:
  Depends on /sys/devices/platform/w83627hf.656/temp1_input
  Controls /sys/devices/platform/w83627hf.656/fan1_input
  MINTEMP=26
  MAXTEMP=37
  MINSTART=70
  MINSTOP=65
  MINPWM=0
  MAXPWM=255

Enabling PWM on fans...
Starting automatic fan control...

/usr/local/sbin/fancontrol: line 379: /tmp/sh-np-14684835713059225396: Interrupted system call
/usr/local/sbin/fancontrol: line 379: /tmp/sh-np-14796770300700131886: Interrupted system call
/usr/local/sbin/fancontrol: line 341: /tmp/sh-np-7856438869544434457: Interrupted system call
/usr/local/sbin/fancontrol: line 379: /tmp/sh-np-16345902315693239451: Interrupted system call
/usr/local/sbin/fancontrol: line 341: /tmp/sh-np-17780533917502166508: Interrupted system call
/usr/local/sbin/fancontrol: line 341: /tmp/sh-np-7920488696791855376: Interrupted system call
/usr/local/sbin/fancontrol: line 341: /tmp/sh-np-7768355284806920479: Interrupted system call
/usr/local/sbin/fancontrol: line 341: /tmp/sh-np-9159311026931131704: Interrupted system call

here is my config: 

INTERVAL=10
FCTEMPS=/sys/devices/platform/w83627hf.656/pwm2=/sys/devices/platform/w83627hf.656/temp2_input /sys/devices/platform/w83627hf.656/pwm1=/sys/devices/platform/w83627hf.656/temp1_input
FCFANS=/sys/devices/platform/w83627hf.656/pwm2=/sys/devices/platform/w83627hf.656/fan2_input /sys/devices/platform/w83627hf.656/pwm1=/sys/devices/platform/w83627hf.656/fan1_input
MINTEMP=/sys/devices/platform/w83627hf.656/pwm2=26 /sys/devices/platform/w83627hf.656/pwm1=26
MAXTEMP=/sys/devices/platform/w83627hf.656/pwm2=45 /sys/devices/platform/w83627hf.656/pwm1=37
MINSTART=/sys/devices/platform/w83627hf.656/pwm2=100 /sys/devices/platform/w83627hf.656/pwm1=70
MINSTOP=/sys/devices/platform/w83627hf.656/pwm2=95 /sys/devices/platform/w83627hf.656/pwm1=65

i'm running kernel 2.5.25, but this show up at least since 2.6.24... im using slamd64 (slackware clone at 64bits) 

# sensors --version
sensors version 3.0.1 with libsensors version 3.0.1

the ps -eo pid,stat,wchan:40,comm for all those process says this: 

(pid#) S+   pipe_wait                                fancontrol

fan control is running fine, so this problem is a bit strange

thanks higuita

Attachments

fancontrol-no-named-pipes.patch (0.6 kB) - added by khali on 05/31/08 16:13:29.
Don't use named pipes in fancontrol

Change History

05/12/08 11:59:07 changed by khali

  • owner changed from somebody to khali.
  • priority changed from major to minor.
  • version set to 3.0.1.
  • status changed from new to assigned.
  • description changed.

This is the first report of that type, and I have no idea what's going on.

Lines 379 and 341 are the same: 

read < <(exec sleep $INTERVAL)

So I guess that this specific construct doesn't work properly for you. This construct was suggested by the maintainer of the Suse sensors package.

Which version of bash are you using? Is "sleep" an internal or external command? "type sleep" should tell.

(follow-up: ↓ 3 ) 05/30/08 20:26:27 changed by khali

Reporter, can you please answer my questions?

(in reply to: ↑ 2 ) 05/31/08 04:48:45 changed by ticket

Hi

Sorry the delay, i have missed this message

On Mon, 12 May 2008 09:59:08 -0000, "lm-sensors" <lm-sensors-notify@lm-sensors.org> wrote:

Which version of bash are you using? Is "sleep" an internal or external command? "type sleep" should tell.

$ bash --version GNU bash, version 3.1.17(2)-release (x86_64-slamd64-linux-gnu)

sleep is external:

$ type sleep sleep is /usr/bin/sleep

$ /usr/bin/sleep --version sleep (GNU coreutils) 6.9

thanks for the help higuita

05/31/08 16:12:34 changed by khali

Apparently bash has two ways to handle named pipes, either using /dev/fd, or creating them in /tmp. Mine does the former, yours does the latter. At least it explains why I couldn't reproduce your problem on my system. I do not know how bash decides what to do, but I've seen different versions of bash do it differently on the same system.

I don't really want to investigate this further, because the simple truth is that we don't need to use named pipes here. This construct was used to let fancontrol handle signals while it sleeps, but there are other ways to achieve this. I'll attach a patch, please give it a try and report if it fixes your problem.

05/31/08 16:13:29 changed by khali

  • attachment fancontrol-no-named-pipes.patch added.

Don't use named pipes in fancontrol

(follow-up: ↓ 6 ) 05/31/08 16:14:19 changed by khali

  • milestone set to 3.0.3.

(in reply to: ↑ 5 ) 06/02/08 03:47:03 changed by ticket

hi again

i'm running for 24H fancontrol with your changes and still didnt find any problem... i think that this problem is solved with that change

thanks for the help :)

higuita

06/02/08 08:24:29 changed by khali

  • status changed from assigned to closed.
  • resolution set to fixed.

Fixed in r5271.