On Wed, 21.07.10 20:13, Matthew Miller (mattdm@xxxxxxxxxx) wrote: > It appears that you're looking at this from the point of view of chkconfig > as a tool which causes certain manipuations of the system to happen > (symlinks changed). That's the backwards approach. Look at it from the other > side: it is a user-interface for changing under what conditions certain > services run. Then extend that user interface to fit the new capabilities > that you're adding. Well, the chkconfig tool is actually a tool which is way more than a dumbed-down access utility to the /etc/rcX.d/ symlink farms. What its implementation actually does is defined very much in detail and for example documented in the man page, to the last bit. In other words: it is *NOT* an implementation detail what exactly it does to enable/disable a service. In fact the interface to chkconfig is defined on a multitude of levels, not only the mere command line arguments. For example we have chkconfig headers in all init scritps which are part of the api of chkconfig. This is for example very different from let's say the sysv "/sbin/reboot" command whose semantics are pretty well known and trivial to understand. It is easy to reimplement that command on top of a different system. But chkconfig? Not so much if you have neither rcN.d links, priorities, nor S or K links -- nor even init scripts at all. The logic behind chkconfig is exposed in many ways in the user interface, for example in the chkconfig command line, e.g. commands such as "resetpriorities", and stuff like that. > > One small and random example, just to make a point: Look how awesome the > > output of "systemctl status avahi-daemon.service" is: > > > > <snip> > > avahi-daemon.service - Avahi mDNS/DNS-SD Stack > > Loaded: loaded (/lib/systemd/system/avahi-daemon.service) > > Active: active (running) > > Main: 6841 (avahi-daemon) > > Status: "Server startup complete. Host name is lambda.local. Local service cookie is 813782141." > > CGroup: name=systemd:/systemd-1/avahi-daemon.service > > ├ 6841 avahi-daemon: running [lambda.local] > > └ 6842 avahi-daemon: chroot helper > > </snip> > > So, um. This is not so awesome, because for logged output, the multi-line > format makes it hard to parse. And for human-readable output, it's got the > opposite problem: it's more than 80 columns, and it's very verbose, > burying the answer I want (is the thing running?) in the middle of the > paragraph, while telling me many things I probably don't care about. Jeez. I guess you cannot be helped. I guess it doesn't help in any way here to mention that we were two steps ahead of you here and provide "systemctl show" which can be used to introspect systemd units in all details and properties in a parsable way. Also, we added "systemctl check" which prints a one line super-short status. But anyway, I give up. If you keep looking long enough you'll find something you don't like in everything. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
