Matthias Saou wrote: > Jarod Wilson wrote : > >>> Perhaps a new third result for initscripts. Instead of just [ok] or >>> [Failed], maybe a new one like [Unneeded] or [N/A] or something. >> We already have a 3rd result, 'warning', but... > > We also have that yellow [PASSED] :-) > I have no idea what the initial idea behind it was. Maybe notting knows. Ah yes, seen that one once or twice too, forgot about that... >>> Might help people realize that these things are running instead of >>> giving them the impression that they are running and using system >>> resources. >> ...Meh. I prefer what we do w/cpuspeed right now. If the support isn't >> there, we silently exit. We never even print out a "starting cpuspeed:" >> or any status. > > This can be a little confusing from a user perspective : "I enabled the > service, so why doesn't it start when I boot?". But scripts wanting to > do this could easily put useful information into /var/log/messages. The cpuspeed case is a bit interesting. We've decided that we're going to start the cpuspeed initscript on every system we possibly can, doing our part to help conserve energy, make users lives easier w/o them having to do anything, etc. At the same time, we don't want a myriad of support calls/bugzillas opened because we alerted the user that we tried to start cpuspeed and failed. We've got logging support in the initscript, so we could certainly log failed startup attempts. I'd just want to word any log message *very* carefully... (Open to suggestions) > A possible solution for "on demand" services would be : > - If the service is disabled, never run it. > - If the service is enabled : > - If the relevant hardware is present, start the service > - If the relevant hardware isn't present, skip starting the service Essentially what cpuspeed does now. > Then once all the hooks are present to be able to start/stop services > upon hot (un)plugging devices, start/stop the service when detecting > the device's addition or removal, if the service is enabled. > > That way we can keep useful services "enabled" by default, although > they'll only actually run if/when the relevant devices are detected. > And we still leave experienced users a way to completely disable > services they wouldn't want running for whatever reason. Would certainly be very cool for stuff like bluetooth support. Not relevant in the cpuspeed case (not saying that you were saying it was, just making sure we're making this distinction). Well, I guess it *could* be relevant if you wanted frequency scaling to start up automagically after you manually load up a module, such as acpi-cpufreq, and the necessary support is suddenly there, but that sounds like a suboptimal way to do things in this particular case... -- Jarod Wilson jwilson@xxxxxxxxxx
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
