Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > 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. You are both right... of sorts ;-) True, chkconfig's workings do show through a lot more than is sane. OTOH, if you need to admin a bunch of Fedora systems, some oldish (i.e., Fedora 11 and 12), perhaps even archeological (Fedora 6 someone? ;-), some new (rawhide, to check out what looms over the horizon), a few RHEL/CentOS boxen of varied vintage, some old versions of Scientific Linux or some such "because that is the latest g++ that compiles our junk", perhaps a few other Linux systems, and your complement of random Windows and Mac boxen, _any_ difference (at least in the most used command options) hurts like hell. The _fingers_ need to know how to do stuff, the _brain_ is better left out of it (much of the time, that is). That's why we still use the same venerable lpr(1) to print stuff, even though the server behind it has changed some 4 or 5 times during my Unix life. Sure, if I need to mess around adding new print queues and such I do engage the brain (and go RTFMing and googleing, and whatnot), but _please_ leave (most used) commands/options legacy compatibility in place. Until this is in RHEL, and a Fedora cycle more or some such. Pretty please. [Snippage] > > 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. Great to know about that. And yes, it is extremely relevant for a sysadmin to know how to tickle the system so it spits out awk(1)-able logs and stuff. > But anyway, I give up. If you keep looking long enough you'll find > something you don't like in everything. Please don't. I'll find something I don't like everywhere (some tell me I'm way too good at that ;-), the point is to make me find enough stuff I _do_ like so I get over the bitter pill. systemd looks interesting enough to be worth the pain up to here, but there are lost of details to be hashed out. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
