https://bugzilla.novell.com/show_bug.cgi?id=864894 https://bugzilla.novell.com/show_bug.cgi?id=864894#c0 Summary: systemd unit files: RFC: provide "superset"/"master" unit files for services Classification: openSUSE Product: openSUSE Factory Version: 13.2 Milestone 0 Platform: All OS/Version: openSUSE 13.2 Status: NEEDINFO Severity: Enhancement Priority: P5 - None Component: Basesystem AssignedTo: systemd-maintainers@suse.de ReportedBy: jsmeix@suse.com QAContact: qa-bugs@suse.de InfoProvider: systemd-maintainers@suse.de Found By: Development Blocker: No Problem: Assume there is one service commonly konwn as "foo" by users. Assume there are various systemd unit files for that service like foo.service, foo.socket, foo.path, basic-foo.service, basic-foo.socket, foo_add-on.service, foo_add-on.path,... Then - as far as I know - there is no simple and safe way for an admin to completely start/stop/enable/disable "foo". Because the unit file names for that service can be more or less random (they even do not need to contain "foo"), I cannot work to use some kind of regular expression matching to get all systemd unit files that belong to what is commonly konwn as "foo". Therefore I suggest the following: The RPM package that provides the various systemd unit files for "foo" should also provide one "superset"/"master" unit file e.g. "foo.master" which is made so that the admin can just call # systemctl [start|stop|enable|disable] foo.master to completely start/stop/enable/disable "foo". I have two questions (RFC - a.k.a. "NEEDINFO"): 1. Is such a "superset"/"master" unit file possible with systemd? 2. If such a "superset"/"master" unit file is possible with systemd how should it look like? My particular use case: Up to openSUSE 13.1 the RPM package cups provided cups.service, cups.socket, cups.path but neither users/admins nor YaST (see https://bugzilla.novell.com/show_bug.cgi?id=857372#c115) were prepared to deal correctly with the various possible ways how the cupsd should/could/would be started/stopped/enabled/disabled. Additionally there is printer.target provided by a different RPM (/usr/lib/systemd/system/printer.target is provided by systemd itself) which also may belong to what is commonly konwn as "cups". Furthermore there is configure-printer@.service (/usr/lib/systemd/system/configure-printer@.service is provided by udev-configure-printer) which also may somehow belong to what is commonly konwn as "cups" or "printing". If such a "superset"/"master" unit file is possible with systemd I would like to provide it for what is commonly konwn as "cups" so that the admin and YaST can just call something like # systemctl [start|stop|enable|disable] cups.master to completely start/stop/enable/disable the cupsd. Additionally I would like to have a "superset"/"master" unit file for the whole "printing" stuff so that the admin and YaST can just call something like # systemctl [start|stop|enable|disable] printing.master to completely start/stop/enable/disable the cupsd plus anything else what is related to "printing" (e.g. cups-lpd and printer.target and configure-printer@.service and so on). In this case I would need that those who know well about systemd provide me at least first well usable examples of such "superset"/"master" unit files for "cups" and for "printing". -- 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.