https://bugzilla.novell.com/show_bug.cgi?id=864894 https://bugzilla.novell.com/show_bug.cgi?id=864894#c3 --- Comment #3 from Johannes Meixner 2014-02-27 16:43:08 CET --- To avoid possible misunderstanding: In comment#0 I wrote "foo.master". I do not care about the name of such "superset"/"master" unit files. I only liked to point out its meaning by using "foo.master" as name. My basic idea behind is to have some kind of main switch to switch off and on "the whole foo thing". For example CUPS: For newer CUPS versions > 1.5.4 there is the "cups-browsed" which is provided by the separated package "cups-filters" and "cups-browsed" also belongs to "the whole cups thing". For all CUPS versions there could be "cups-lpd" (which is currently started via xinetd). Finally there is the core CUPS service "cupsd". Accordingly one could have the individual unit files - cupsd.service - cups-lpd.service - cups-browsed.service To completely start/stop/enable/disable "the whole cups thing" there could be a "superset"/"master" unit file - cups.service (or whatever its name is) Perhaps by using appropriate dependencies in the unit files such "superset"/"master" unit files are already possible? But there is an issue that makes it tricky: The main switch idea behind means that for example after # systemctl stop cups.service # systemctl start cups.service the same individual services that had been running before the stop now run again (e.g. if cups-lpd was not running before the stop, it should not be running after the start). The main switch semantics is meant to be the same as when you have several stateful/bistable individual on/off light switches plus a main switch. Switching the main switch does not alter the state of the individual switches. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=864894 https://bugzilla.novell.com/show_bug.cgi?id=864894#c5 Johannes Meixner changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |thomas.blume@suse.com --- Comment #5 from Johannes Meixner 2014-09-12 11:38:07 CEST --- To avoid possible misunderstanding I like to point out that I wrote in comment#0: Because unit file names can be more or less random, it cannot work to use some kind of regular expression matching. This means the current systemctl wildcard feature as in # systemctl start cups* # systemctl stop cups* is helpful for an admin who types in systemctl commands but it is not the solution that I like to have. Furthermore it does not work for "enable/disable": ---------------------------------------------------------------------- # rpm -q systemd systemd-210-34.9.x86_64 # systemctl list-unit-files | grep cups cups-browsed.service disabled cups.service disabled # systemctl enable cups* Failed to execute operation: No such file or directory # systemctl enable cups.service # systemctl enable cups-browsed.service # systemctl list-unit-files | grep cups cups-browsed.service enabled cups.service enabled # systemctl disable cups* && echo ok || echo failed ok # systemctl list-unit-files | grep cups cups-browsed.service enabled cups.service enabled ---------------------------------------------------------------------- At least in systemd-210 the systemctl wildcard feature is in practice unusably broken. Even if the systemctl wildcard feature would work in practice it is questionable if tools like YaST support it. If not it also does not help to really solve the issue for normal users. In the end - from my current point of view - the systemctl wildcard feature is only helpful for an admin who types in systemctl commands but it is not a solution for normal users. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.