| Summary: | RFE: Extend systemd service fileformat support configuration tools. | ||
|---|---|---|---|
| Product: | systemd | Reporter: | oiaohm |
| Component: | general | Assignee: | Lennart Poettering <lennart> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
oiaohm
2010-10-11 05:54:51 UTC
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.