Re: [libvirt] [PATCH 00/10] Console coruption with two or more clients series
On 10/18/2011 12:34 PM, Daniel P. Berrange wrote:
On Wed, Oct 12, 2011 at 03:43:10PM +0200, Peter Krempa wrote:
> This series fixes anoying console corruption if two clients try to connect
> at same time to the console. The current state of this is, that two/more
> of libvirt iohelpers are spawned on the same time that compete for data
> from the pty. This causes that each of the consoles get scrambled and
> unusable.
>
The problem with doing the console checks by looking for an in use
virStreamPtr is that it only solves it for apps using libvirt. If
someone connects using 'xm console' or 'minicom' then we're not
protected.
I agree :(.
The traditional way to protect PTYs from concurrent usage is to place
a lock file in /var/lock with a special standardized naming scheme.
Should we perhaps be doing that instead ?
I think, we should be doing this _along_
with alowing libvirt users
to break existing connections while using libvirt. My main reason for this
is that, if someone would open a console connection and successfully
acquire the lock on the pty and then leave for extended period, while
his connection is ok (Jiri's patches will handle crashed conections),
he would effectively block other users from accessing the console. Same
may happen if somebody uses an external tool, to acquire the lock,
but in that case, we can't do anything (identifying the process that
holds the console pty open and killing it is probably not what we want
to do).
IMO, while using libvirt, the users will prefer to use the console
provided by libvirt, and not to tinker with minicom/etc, so while
it'd be still possible to block potential console users, it would
at least handle the most common mistakes. (It will still be possible
to break the console,by manually removing the lock file, etc ...).
I think that addition of lockfile checking will improve this patchset,
but doing it solely that way could be confusing for some and cause
problems.
Peter
Daniel