Improved Systemd Support
Nowadays, the services list is in need of some improvements and fixes. Perhaps, the most important problem is that it lacks of support for "On Demand" services (those services that can be activated via sockets). But, additionally, we would like to propose other UI improvements.
Here is the currnet UI:
You can find an screenshot of the proposed UI below:
Take into account that it is just a mockup and, although some parts are already working, others only
contain some testing data (like the Status column).
Let's explore the changes.
Currently, the Services Manager dialog allows to enable or disable a service by using the "Enable/Disable" button. This button simply changes the service to be enabled "on boot" (enable) or "manually" (disable). But some services also support on demand activation. For this case, the "Enable/Disable" button is useless.
The less aggressive change from UI point of view might be to replace the current "Enable/Disable" button for a combo-box with 2 or 3 options (depending on the selected service supports sockets activation). So, that combo-box would have the following options:
- On Boot
- On Demand
- Manually
The option "On Demand" only is shown when the service can be activated via socket. And also, the current enable mode for the selected service is pre-selected in the combo-box when changing between services in the list.
You can see it in action in this screencast.
The "Active" column was designed in the pre-systemd era and it is too simplistic. Nowadays, systemd
services can be in different status beyond "active" and "inactive". So instead of mapping those
values, we might consider showing the real status (like active (exited)).
The "Start/Stop" buttons label should be updated depending on the service which is already selected. For instance, if a service which is stopped is selected, the button label should be "Start". And viceversa.
A Restart button might be handy, although the user is able to push the Start/Stop button twice.
When some service fails to start/stop, it is useful to have access to service logs. Adding a "Show Logs" button might be handy.
Currently there are three YaST modules that allow to configure service enablement/disablement that also have socket support. This means it should allow user to configure the service to be started on demand.
Already adapted and working. Done as part of xinetd drop.
Currently the module displays start on boot but, in fact, it simply enables the socket (so it is really like starting on demand). We would need more than 1 man/day to solve this problem.
Currently mention start on boot, but inside there is a mixture services and sockets. Extending this module to support both, on demand and on boot, is quite risky. Actually, dependencies between services are not clear at all (we expected that iSCSI would use a service which already defines its dependencies). We might need to do some additional research to clarify things a bit.
Currently, AutoYaST does not support services activation via sockets, so we might need to extend the services-manager section in order to support them.
However, this section is processed during 1st stage, so an installer update (self-update) will be needed in order to offer that feature to our users.