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

Re: [Nbd] nbd-client: small proposal for imporment



The "-d" option does not work in every cases, in the case of PXES thin client, 
you can apply as many "nbd-client -d" on the server to disconned the CD on 
the thin-client, this will not allow you to eject a CDROM !!!

I suppose that this might be considered as a bug in nbd-server shipped with 
PXES, but it is the way it works. When is it receive a disconnecte order 
should the server close of then descriptor it as on the device, or does it 
only send an iotcl to notify the disconnection ? On this is sure on PXES you 
cannot eject the CD until you kill "nbd-client".

The other reason to kill nbd-client is that if you want to use nbd-client in 
dynamic mode, here again in my case thin client. You only want nbd-client to 
start when the user connect on the station and you want it to terminate when 
the user logout. For what I have seen "nbd-client -d" does not terminate the 
running process.

I don't say '-d" is not usefull, but that in thin client deployment cases "-k" 
would be very usefull.

Fulup

Le Vendredi 14 Octobre 2005 11:40, Wouter Verhelst a écrit :
> On Fri, Oct 14, 2005 at 11:28:01AM +0200, Fulup Ar Foll wrote:
> > proposal for improvement:
> > ----------------------------------------
> > In order my nbd-submount process to be able to kill the nbd-client you
> > need to know the PID of the process and unfortunately nbd-client does not
> > write any PID file. I see two options to slove this problem:
> >
> > 1: nbd-client to apply the same mechanism as nbd-server and write a PID
> > file in "/var/run/nbd-client.MY-SOCK-NUM.pid"
>
> No. nbd-client has a '-d' option, which is the proper way to disconnect
> a client; see the man page for details. Killing it will probably not
> work, and if it does might be dangerous, because once the client runs
> the ioctl() which hands the network socket to the kernel and starts the
> block device, it remains in kernel mode until the kernel disconnects the
> block device somehow.



Reply to: