Improving the offline updates user experience

Reindl Harald h.reindl at
Tue Oct 21 20:21:36 UTC 2014

Am 21.10.2014 um 22:08 schrieb Lennart Poettering:
> On Fri, 12.09.14 18:37, Reindl Harald (h.reindl at wrote:
>> 1 out of a million cases needs offline updates
>> really - the only good at it is that you can stick
>> at using YUM and decide what you have to do at your
>> own - rarely updates really require a reboot
>> * lsof | grep DEL | grep /usr and restart services on servers
> Well, some deps are not visible like that, because they do not involve
> continuous mappings or open fds.

may be true but in practice no problem over many years

> Moreover, it won't help you much anyway, as some daemons are not
> restarble right now, most prominently dbus-daemon

you repeat that again and again while i restart dbus over years on 
headless machines for web/file/db-servers and frankly before F15 even 
messagebus was completly disabled on all that machines

> And strictly speaking as you cannot restart all daemons at the very
> same instant, or even at the same instant as you install the new files
> and remove the old ones you will always have races where daemons might
> make use of resources or interfaces that are either newer than what
> they expect or older.

interesting is that not so long ago there where just not much such 
dependencies - mandatory presence of dbus is very recent

other services like some webapp talking to a db-server? frankly i wrote 
10 years ago db-layers to wait and retry so you can restart the db 
server after an update

> offline updates are really about make updates fully reliable. Yes, in
> most cases a "yum update" during runtime works well enough, and yes, I
> usually do my updates that way too. But I am actually able to help
> myself if something goes wrong. And so are you.


> Offline updates are more for the cases where things need to be
> reliable, because no well educated admin is available to instantly fix
> things. Possibly because the machine is used by noobs only, or because
> the machine is buried somewhere under the see, or where so many
> instances of the machine are running that a human admins don't scale
> Hope that makes some sense

yes, but keep in mind not introduce more and more dependencies to make 
them mandatory somewhere in the future

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the devel mailing list