Bug 13087 - alsa addon service status always shows "stopped"
Summary: alsa addon service status always shows "stopped"
Status: CLOSED FIXED
Alias: None
Product: IPFire
Classification: Unclassified
Component: --- (show other bugs)
Version: 2
Hardware: x86_64 All
: - Unknown - Aesthetic Issue
Assignee: Adolf Belka
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-04-18 18:40 UTC by Arno Jonker
Modified: 2023-06-12 18:40 UTC (History)
2 users (show)

See Also:


Attachments
Screenshot Add-On - Services Page (133.20 KB, image/png)
2023-04-18 18:40 UTC, Arno Jonker
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Arno Jonker 2023-04-18 18:40:01 UTC
Created attachment 1148 [details]
Screenshot Add-On - Services Page

The alsa addon always shows status stopped. The initscript does not have a status command option (only start|stop). The services page uses the status command to show what the status of the service is.
Comment 1 Adolf Belka 2023-04-20 13:30:06 UTC
I have looked through the initscript and done a lot of reading on the alsa package.

I now understand that alsa is not running as a typical daemon service. It is provided by kernel modules.

The initscript does not start and stop alsa in the traditional approach.

The start loads two alsa modules which then triggers other dependent alsa modules to be loaded. Then alsactl restore is run which restores andy configuration previously saved.

The stop runs alsactl store which stores the current configuration.

So alsa is not a service in the intention of the addon services table.

Therefore I will raise a patch to remove the service label from it as @Arno originally suggested in the forum where the problem was first flagged.

I have also noted that when the alsa addon is first installed the initscript links are created but the initscript is not run so the required modules would not be loaded unless IPFire was rebooted.
Once the modules are loaded, then if alsa is uninstalled those modules stay in place until IPFire is rebooted.

I confirmed this on my IPFire system. The modules stayed in place after alsa was uninstalled and a reboot was needed to remove all the alsa related modules.

So I will also raise a patch that adds the start option from the initscript to the install.sh pak file and unload the modules in the uninstall.sh pak file.
Comment 2 Adolf Belka 2023-04-21 21:19:21 UTC
patch set submitted to dev mailing list and to patchwork.

https://lists.ipfire.org/pipermail/development/2023-April/015800.html
https://patchwork.ipfire.org/project/ipfire/list/?series=3593
Comment 3 Adolf Belka 2023-05-09 11:55:37 UTC
V2 version of patch set submitted based on feedback from Arne Fitzenreiter.

https://lists.ipfire.org/pipermail/development/2023-May/015856.html
https://patchwork.ipfire.org/project/ipfire/list/?series=3622
Comment 5 Adolf Belka 2023-05-20 13:22:42 UTC
Core Update 175 Testing has been released

https://blog.ipfire.org/post/ipfire-2-27-core-update-175-is-available-for-testing
Comment 6 Adolf Belka 2023-05-20 13:23:47 UTC
Confirmed that when alsa is installed that it no longer shows up in the addon services list.

Also confirmed that when alsa is uninstalled the sound modules are then unloaded.
Comment 7 Adolf Belka 2023-06-12 18:40:57 UTC
CU175 released

https://blog.ipfire.org/post/ipfire-2-27-core-update-175-released