Tom Hacohen <[email protected]> writes:
>
> On Thu, Mar 25, 2010 at 1:21 PM, "Sybren A. Stüvel" <[email protected]> wrote:
> >
> > Some daemons check for usage first, i.e. KDM
> > doesn't restart when a user is still logged in. I've seen plenty of
> > other daemons restart though, such as Bind and PostgreSQL.
>
> In our case, all the daemons are pretty much used all the time. (Even if the
> only maintain state of some resource like gsm).
> Don't you think?
The upgrade-process is also different on OpenEmbedded-based systems
than it is in a lot of desktop-oriented systems: APT, for example,
ensures that *all* necessary packages are downloaded *before*
being installed/upgraded; where ipkg does `download, install,
download, install...' for each individual package--presumably
because there's a question of whether there's actually space
to store all of the packages simultaneously on systems where
OE is deployed.
This does mean that some service-restarts can be much more
problematic on OE: if the network goes down, you can't
finish your upgrade.
Desktop systems actually, in general, don't have an `all or nothing'
policy with regard to restarting daemons on upgrade, but they do
tend to restart them where it's straightforward to do so:
* KDM/GDM/XDM don't restart unless there are no active logins,
in which case they do restart.
* D-BUS never restarts, because it's too pervasive
and there's a `D-BUS should never need to be restarted'
culture accepted by both the developers of the server
and developers of client-applications.
* OpenSSH does restart (it doesn't kill active connections).
* BIND does restart (it probably does kill active connections...
but it's DNS: there probably aren't any active connections to kill).
* Things that would actually break if they tried to keep running
after their components were changed-out unerneath them...
are always restarted.
Speaking at least from Debian and its derivatives, there are also
other situations in which daemons will be restarted: when libc
or the SSL/TLS libraries are upgraded, a prompt is issued like
"The following daemons use SSL but cannot make use of the security-fix
that you just installed until they are restarted. Do you want
to restart them now?".
So, I'd caution that these decisions really should be made on
a case-by-case basis rather than with a heavy-handed dogma--
be it either "we're not going to restart any daemons" or
"we're going to restart all daemons".
You're mostly right about `all daemons are running all the time'
point on SHR, though--*many* of them are in that class where restarting
them almost certainly does more harm than good. Try to keep them
written such that they don't go crazy when stuff changes out from
underneath them, as per the last point in the bullet list above :)
I wonder if there are other phone-based upgrade-systems to which
we can look for guidance--even if they're significantly different,
there might be areas where SHR is more analagous to them than to desktops.
--
"Don't be afraid to ask (λf.((λx.xx) (λr.f(rr))))."
_______________________________________________
Shr-devel mailing list
[email protected]
http://lists.shr-project.org/mailman/listinfo/shr-devel
