Description of problem: After installing lm_sensor package (Dell Optiplex 990, i586) booting gives: Failed to start Initialize hardware monitoring sensors See 'systemctl status lm_sensors.service' for details. <harms@pcjuergen ~> systemctl status lm_sensors.service lm_sensors.service - Initialize hardware monitoring sensors Loaded: loaded (/lib/systemd/system/lm_sensors.service; enabled) Active: failed (Result: resources) CGroup: name=systemd:/system/lm_sensors.service Version-Release number of selected component (if applicable): <harms@pcjuergen ~> rpm -qa | grep sensor libqtsensors1-1.2.0-5.mga2 lm_sensors-3.3.2-6.mga2 liblm_sensors4-3.3.2-6.mga2 How reproducible: 100% Steps to Reproduce: 1. install the lm_sensors package 2. do a boot 3.
Did you run sensors-detect? Does it help?
CC: (none) => sander.lepik
Thank you, that solves the issue, and sorry for the false alarm. But, it would make sense if systemctl status could suggest running sensor-detect. Is this possible, does it make sense to file an enhancement bug?
Yeah, it would be nice if it informs about this.
Hardware: i586 => AllSummary: lm_sensors service start fails (testing RC) => lm_sensors service start fails (it should warn if sensors-detect needs to be run)Severity: normal => enhancement
CC: (none) => mageia
Same issue in the installer of Mageia 2. (installing lm_sensors package without running sensors-detect).
CC: (none) => g.sprikComponent: RPM Packages => Installer
There is a README.urpmi file which warns about running sensors-detect. I believe that it is supposed to be displayed when installing lm-sensors, but I can't remember if it was displayed when I installed lm-sensors on Mageia 2.
Hi, This bug was filed against cauldron, but we do not have cauldron at the moment. Please report whether this bug is still valid for Mageia 2. Thanks :) Cheers, marja
Keywords: (none) => NEEDINFO
I updated the version to Mageia 2. 1) I get the message after the install to run "sensors-detect". 2) One of computers only uses driver "k8temp", which autoloads. - This means that "/etc/sysconfig/lm_sensors" is not created. - This means that the service always fails
CC: (none) => jeffrobinsSAEVersion: Cauldron => 2
Keywords: NEEDINFO => (none)
OK, so I think this is one solution: Modify the lm_sensors.service file to look like this: [Unit] Description=Initialize hardware monitoring sensors After=syslog.target [Service] EnvironmentFile=-/etc/sysconfig/lm_sensors Type=oneshot RemainAfterExit=yes ExecStartPre=/bin/sh -c "if [ ! -f /etc/sysconfig/lm_sensors ]; then echo 'You must run sensors-detect first' >&2; exit 1; fi" ExecStart=-/sbin/modprobe -qab $BUS_MODULES $HWMON_MODULES ExecStart=/usr/bin/sensors -s ExecStop=-/sbin/modprobe -qabr $BUS_MODULES $HWMON_MODULES [Install] WantedBy=multi-user.target (note that the EnvironmentFile line now has a - in it to ignore any errors if the file does not exist). Then there is a pre command that checks if the file does not exist and if it does not, it echos a warning. This warning should then show up in "systemctl status lm_sensors.service" to give the user a hint as to what is wrong. Sadly this doesn't seem to actually work! The journal does not appear to capture that output and thus it's not shown with the systemctl status output. I'll see what upstream suggest here.
I actually do have the line in /var/log/messages, but the process is "sh" and not "systemd". The other problem is that I still get a failure because there are no arguments for modprobe. Output of "systemctl status lm_sensors.service" after a restart: [root@PITA_Linux multi-user.target.wants]# systemctl restart lm_sensors.service Job failed. See system journal and 'systemctl status' for details. [root@PITA_Linux multi-user.target.wants]# systemctl status lm_sensors.service lm_sensors.service - Initialize hardware monitoring sensors Loaded: loaded (/lib/systemd/system/lm_sensors.service; enabled) Active: failed (Result: exit-code) since Mon, 04 Jun 2012 23:48:36 -0700; 10s ago Process: 5288 ExecStop=/sbin/modprobe -qabr $BUS_MODULES $HWMON_MODULES (code=exited, status=1/FAILURE) Process: 5290 ExecStartPre=/bin/sh -c if [ ! -f /etc/sysconfig/lm_sensors ]; then echo 'You must run sensors-detect first' >&2; exit 1; fi (code=exited, status=1/FAILURE) Main PID: 5145 (code=exited, status=0/SUCCESS) CGroup: name=systemd:/system/lm_sensors.service Jun 04 23:48:35 PITA_Linux sh[5290]: You must run sensors-detect first
(In reply to comment #9) > I actually do have the line in /var/log/messages, but the process is "sh" and > not "systemd". > > The other problem is that I still get a failure because there are no arguments > for modprobe. > > Output of "systemctl status lm_sensors.service" after a restart: Ahh interesting. I didn't see that here in the status output but that's exactly what I wanted to happen :) Perhaps it didn't show up for me due to a manual start of the service rather than a proper reboot! You can add another line above EnvironmentFile= line that reads: Environment=BUS_MODULES=dummy-sensor-module That should mask the modprobe error. If that all works nicely, then I think this is a sufficient solution. WDYT?
I still get a failure and always will according to the script, but I've noticed that modprobe quit complaining, even before I added the line to the lm_sensors.service file. I looked through past boots and only the boot on June 4th had the error. If I remove the new environment line, then I still get no complaints from modprobe. --Jeff
Problem is in package lm_sensors in Mageia 2. Syslog: Mar 24 11:23:40 localhost systemd[1]: Unit lm_sensors.service entered failed state. Mar 24 11:23:40 localhost systemd[1]: Failed to load environment files: No such file or directory Mar 24 11:23:40 localhost systemd[1]: lm_sensors.service failed to run 'start' task: No such file or directory Solution: touch /etc/sysconfig/lm_sensors File /etc/sysconfig/lm_sensors exists in package lm_sensors for Mageia 3. It means package lm_sensors for Mageia 2 is needed rebuilding with /etc/sysconfig/lm_sensors.
CC: (none) => loginov_alex
Assigning to lm_sensors' maintainer
Keywords: (none) => TriagedComponent: Installer => RPM PackagesAssignee: bugsquad => mageiaSource RPM: (none) => lm_sensors
This message is a reminder that Mageia 2 is nearing its end of life. Approximately one month from now Mageia will stop maintaining and issuing updates for Mageia 2. At that time this bug will be closed as WONTFIX (EOL) if it remains open with a Mageia 'version' of '2'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 2's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Mageia 2 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete. -- The Mageia Bugsquad
Mageia 2 changed to end-of-life (EOL) status on ''22 November''. Mageia 2 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Mageia please feel free to click on "Version" change it against that version of Mageia and reopen this bug. Thank you for reporting this bug and we are sorry it could not be fixed. -- The Mageia Bugsquad
Status: NEW => RESOLVEDResolution: (none) => OLD