Upgrade to 170, 2 services show as not running

After the update to 170, both cpufreq and messagebus show as down in the GUI. I’m not sure how to check the cpufreq service, but running /etc/rc.d/init.d/messagebus status shows a pid. so it might simply be a detection issue, any suggestions?



The way that addons are identified as being a service or not was modified in CU170. This uses the status command from the initscript.

For cpufreq there is only a start command in the initscript, no stop or status command so that always shows stopped even when it is running.
A bug entry has already been raised for that.

With messagebus there is a status command and it includes the words “is running” when running and “is not running” when it isn’t so it should work, but I can confirm that I have obtained the same result on my vm testbed as you are reporting.

There must be some other issue with the messagebus package.
Can you please raise a bug for this issue.

Your IPFire people user name and password also apply as the login credentials for IPFire Bugzilla.

1 Like

The message bus script returns on the status command: dbus-daemon is running with Process ID(s) 1894.

But something must have changed, as with 169 I saw all services running on the webgui. I’ll raise the bug. Thnx

You don’t need to raise a bug for it, if you haven’t yet. There is also a bug raised for the same issue with nrpe and I think I have figured out the cause for the problem.

I have taken the nrpe bug and will include messagebus and any other addons that suffer from the same problem.

The looks to be that the package name is called one thing but the initscript is called something else so.

dbus has the initscript as messagebus and
nagios-nrpe has the initscript as nrpe.

The services.cgi page looks for the addon via the meta-* file which uses the package name and compares it to the initscript and if the meta file is not found with the initscript name it says that the addon was not found.

If you have already raised the bug, don’t worry, I will mark it as a duplicate of the nrpe one.


for messagebus see bugzilla bug: 12916#c7

Hi Jon,

The problem being raised here is that the Services page shows the addon is Stopped but if you test with the initscript is shows it is running.

The problem here is that addonctrl takes the services name given in the LFS file and checks for the addon meta file using that name.

For messagebus/dbus this means that addonctrl looks for meta-messagebus but the file is actually called meta-dbus because the LFS package name is dbus but the service initscript name is messagebus.

I haven’t figured out yet why it used to work with the old services.cgi - I need to look at the differences.

The reason it was not a problem with messagebus and npre in the past is that they were never shown in the addon services table at all. The old code checked if there was an initscript witrh the name of the package and if not then that addon was definmed as not being a service. So the code looked for an initscript called dbus.
The same thing is occurring with the package name nagios_npre where the initscript is named npre.

I don’t believe that this issue with messagebus being shown as stopped in the services page when it is actually running is related to your original bug12916.

1 Like

I hadn’t, I see others have worked out why I’m seeing that, didn’t realise they never showed previously, but I do remember seeing all green’s. But the explanations seems to nail it on the head. Thnx to all that explained so quickly and clearly.