On Mon, 18 Jun 2012, Richard Hughes wrote:
On 18 June 2012 00:38, Reindl Harald <h.reindl@xxxxxxxxxxxxx> wrote:
the point is that it was perfectly possible in 2005 to make a fedora
dist-upgrade at friday night while http, netatalk or samba was
fully up and running until saturday sometimes at evening where
you rebootet the machine and now EIGHT years later we discuss about
making updates at reboot/offline like windows?
Well, if you're running a headless server with just http, netatalk and
samba then you can of course update now live using yum, restarting
services when convenient. I'm not going to change that. What I want to
change is for the case of updating a fully functioning desktop with
~30 session processes per user talking to each other over session
DBus, ~20 doing IPC with system DBus, and ~15 processes in the system
context, ~3 of which do DBus IPC with each other. That's about as far
removed from a simple server with three non-connected daemons that do
one thing each as you can get.
something must have gone terrible wrong in the meantime
If your goal is to just run three simple daemons, I agree.
As dbus is required for various things like networkmanager - does this
mean that if a server happens to be using nm for network setup that in
order to apply a security patch to dbus, for example, that the server will require
a reboot?
Since more and more we're relying on dbus for server-y processes it feels
like we'll be adding one more component that requires a reboot for updates
to take effect. That eats up real time and causes real pain later on for
admins maintaining systems.
Either we need to make dbus something we can sensibly restart or we need
to rely on it less for server-y tasks (or both).
I understand you're not working on PK for servers but the packaging
expectations will trickle down to our slower-changing server installations
and this will cause real pain and irritation. The implications for servers
are fairly serious.
-sv
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
