[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Checking if another package is upgraded at the same time

On Thu, Mar 23, 2006 at 10:50:38AM +0200, Kari Pahula wrote:
> Restarting crossfire-server will cause any remote players to have their
> connection abrubtly broken and to lose any progress that they've had since
> their logon.  That's not quite what I'd call a smooth upgrade.

I don't know if you are upstream yourself, or if upstream is likely to accept
large patches from you, but there is a real solution to this problem.  I'd say
the problem really is that you cannot upgrade your maps without the players
being disconnected.

First of all, I point out that you will want the newly installed maps to be
usable, so not restarting the server because there are still players on it is
not acceptable.  There are some options to really solve this:
- If you can change the server so that it can use the new maps without a
  restart, that would obviously solve the problem.  You can either do this by
  always looking on disk, so the new maps are found when needed, or in the way
  inetd does it, by rereading config files at SIGHUP.
- You can also do it like ssh: every connection is forked off when
  established.  Then when the server restarts, the connections continue to
  exist.  If you need clients to talk to each other, then this is probably not
  an option.  It also won't work if existing clients need the new maps.
- The coolest approach IMO (but probably not the least error-prone) is to use
  execv's behaviour of keeping fd's open.  It is a huge security design bug
  that this is the default, but the possibility is nice. ;-)  What it means is
  that you can restart the server without losing your connections.  You need
  to tell the new executable about the open file descriptors (for example via
  some temporary file).  Then if started with a "use this temporary file for
  state" option, it reads the file descriptors from there and uses them.

> Is it reasonable to expect users to expect this behavior on upgrading the
> maps?

I don't think so, but it's acceptable if fixing it is not feasable.

> Would it be enough to put in crossfire-maps description that upgrading maps
> will cause the server to restart?

It depends on how you think the package will be used.  I think in most cases
it is better to do the restart, but perhaps you want to add a debconf low
priority question if the user really wants this.  Then the default is to
restart, and people running huge servers which want to keep their clients can
use dpkg-reconfigure and manually restart when it is appropriate for them.

> At least I think I can safely assume that users will know to expect
> that upgrading the crossfire-server package itself to cause the server
> to restart.

Yes, but even in that case it would be nice if the clients don't get
disconnected. ;-)


I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see

Attachment: signature.asc
Description: Digital signature

Reply to: