just been looking at systemd service fileformat. In the [Unit] I don't seen any reason why optional entry "configmenu=" could not be add with a value of a directory containing .desktop point to applications/webinterfaces used to configure the service. .desktop files chosen for a few key reasons. Its a existing file format. http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html It contains all the information to sort between a weblink, commandline app and a graphical app. Finally directory struct could be a sub tree of the already existing menu system. Double use. If systemd is not being used at long last provide a way to find what config tools config what. Also this does encourage development of configuration tools. All above here would not have to be processed by systemd but to assist management tools. Also a "testconfig=" option would also be handing for services that failed to run. No point trying to restart a service if it configuration files are damaged. This does join in with list of configuration tools. If testconfig fails on a service that user is attempting to start offer user configuration tools to correct issue. This is duel use assist management tools to work out in advance if a process can or cannot operate and provide user with sane feedback. Also prevents systemd wasting it time attempt to start processes that will never stay running due to defective configuration. Ie service fails to start check configuration if configuration bad disable until configuration is fixed.
Sorry for posting to comments in a row. I just worked out I was being tunneled visioned. configmenu= does have a valid use with systemd starting a system that otherwise will not start. It will enable 3 options instead of 2 to be provided when running a safemode. Normal safemode is run or not run. Third option reconfigure. testconfig would kinda be automatically running in safemode. If testconfig fails service cannot be started so not run or reconfigure would be offered ie no run. Yes people do stuff there systems up. Yes up until now Linux repair modes have not been guided instead basically get user to bash shell and pray the know what todo or create a general mayday mode and hope nothing in depends on has stuffed. Guided has many advantages you don't try repairing stuff that is not being run and is not required so just making matters worse not better. Also it can provide the option to check and reconfigure everything that is used in boot. I really think providing this would be a first. I know windows and all Unix's BSD I have used cannot do it. Hopefully the quality of tools to end configuration files improve so making it simple for new users to repair and configure their own system. But first we have to provide services with a reason to make them. Better quality integration into the boot process is a reason. Sorry to say in seeing I was being tunnel visoned I worked out a third would be nice. restoredefaults=<command> Simply return service settings to the same as the very day it was installed including disabling it from running if that was the default installed state. With these 3 extras in the systemd service config files friendlessness can be increased and hopefully long term repairing Linux system to operational state many never require a command line again.
Note that the format is extensible by default. i.e. people can make use of X-Foobar= settings as they wish, similar to how extensions for .desktop work. Before we make an option like this standard by dropping the X- prefix the respective implementors should code something up with the X- prefix and shows that it works. Or to summarize this: write the UI first, use a X-Foobar= property and then eventually ping us.
Checking finer details. Before going ahead and coding. Will be needing to play with systemdadm the graphical front end for prototype these features. Using these is not writing a new UI. Its extending the existing. The graphical side is fairly simple. restoredefaults=<command> Will be the simplest part do first. Add button to systemdadm restore defaults with a yes/no dialog. testconfig=<command> This will be a little harder. testconfig will take in playing with systemdadm program. I guess coloring rows to show config status would not be good instead have to add a column showing config status? Also altering systemdadm to prevent starting of processes that testconfig on them fails. Allow stopping just not allow starting. This will also involve display output of the testconfig program when it fails. And to make configmenu= to part work. Value in configmenu for graphical could be just a extra button in systemdadm called "configure" executing command "xdg-open <value>" for displaying. With the fine details on how to process and display .desktop files worked out latter? That has to be done latter for textmode support. Maybe latter change into a pop up box listings. Yes the exact style to display the config menu I have not worked out yet and is going to be a little bit of trial and error. Textmode processing of .desktop files will take some more research so these features can be integrated into systemd as a start up mode like the old single in initd but with more friendly treatment to resolve case where defective configuration that is causing startup failures. I think its most likely wise if I don't there first. Basically are any of the alterations I am considering of systemdadm for making prototype are these alterations going to interfere with what you are doing. Yes I know I need to prototype so bugs in design can be found. I really don't like changing other people GUI interfaces without asking just incase they have something else planned to go somewhere. Sorry I really should have stated I was planing on playing with systemdadm in first two messages on the bug.
I don't think this really belongs in systemd, and can be implemented with X- lines. Closing.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.