too many deamons by default - F7 test 2 live cd

[Jarod Wilson]

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 at redhat.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20070320/2ea18a3f/attachment.sig>