[Users] /dev/fd/3

[Matt Ayres]

The same bug exists in Virtuozzo, "ln -s /proc/self/fd /dev/fd" appears 
to be the fix.

Reference: http://www.tektonic.net/forum/showthread.php?t=1936

Steve Hodges wrote:
> On 14/08/2007 1:58 AM, Gregor Mosheh wrote:
>>
>> Or perhaps your VE has maxed out the number of FDs it's allowed to 
>> have? Check the /proc/user_beancounters and see if anything there is 
>> happening to shed light on whether the failure is VE-related.
>
> Here is what I see, including the beancounters immediately after
>
> Executing 'mkisofs -C 106736,113120 -M /dev/fd/3 -R -J -pad 
> -graft-points /2007-08-14__12-07-50=/home/archive/image | builtin_dd 
> of=/dev/hdc obs=32k seek=7070'
> genisoimage: No such file or directory. Cannot open '/dev/fd/3'. 
> Cannot open SCSI driver.
> genisoimage: No such file or directory. Unable to open previous 
> session image '/dev/fd/3'.
> :-( mkisofs has failed: 2
> ***image written
> ***error writing to DVD. You may need another DVD
> root at backup:/# cat /proc/user_beancounters
> Version: 2.5
>       uid  resource           held    maxheld    barrier      limit    
> failcnt
>      111:  kmemsize         509969     691152    2752512    
> 2936012          0
>            lockedpages           0       8905      30000      
> 30000          0
>            privvmpages        1778      18792     100000     
> 200000          0
>            shmpages              0          0       8192       
> 8192          0
>            dummy                 0          0          0          
> 0          0
>            numproc              10         14         65         
> 65          0
>            physpages          1112       9981          0 
> 2147483647          0
>            vmguarpages           0          0       6144 
> 2147483647          0
>            oomguarpages       1112       9981       6144 
> 2147483647          0
>            numtcpsock            3          3         80         
> 80          0
>            numflock              1          2        100        
> 110          0
>            numpty                1          1         16         
> 16          0
>            numsiginfo            0          2        256        
> 256          0
>            tcpsndbuf             0          0     319488     
> 524288          0
>            tcprcvbuf             0          0     319488     
> 524288          0
>            othersockbuf       2220       2904     132096     
> 336896          0
>            dgramrcvbuf           0          0     132096     
> 132096          0
>            numothersock          2          4        120        
> 120          0
>            dcachesize            0          0    1048576    
> 1097728          0
>            numfile             237        317       2048       
> 2048          0
>            dummy                 0          0          0          
> 0          0
>            dummy                 0          0          0          
> 0          0
>            dummy                 0          0          0          
> 0          0
>            numiptent            10         10        128        
> 128          0
>
> the lines flagged with *** come from my script.
>
> the relevant lines of the script are:
>
> # create a path on the dvd
> writedate=$(date +%Y-%m-%d__%H-%M-%S)
>
> # burn files to dvd (either new or append) in timestamped directory
> # might be a good idea to log this fact too.
> err=
> case "$dvdstatus" in
>  blank)
>    growisofs -Z /dev/hdc -R -J -pad -graft-points 
> "/${writedate}=${image}" || err=Y
>    ;;
>
>  appendable)
>    growisofs -M /dev/hdc -R -J -pad -graft-points 
> "/${writedate}=${image}" || err=Y
>    ;;
>
>  *)
>    echo Internal error deciding how to write to dvd
>    exit 1
>    ;;
>
> esac
> echo image written
>
> # if error then send email and ask for new dvd (reporting error too)
> if [[ "$err" == "Y" ]]; then
>  echo error writing to DVD.  You may need another DVD
>  eject
>  exit 1
> fi
>
> (clearly the script isn't complete yet :-)
>
>>
>>
>>> I also find that whilst I have made /dev/hdc available to my VE, I 
>>> can't mount the cdrom.  It tells me
>>> mount: unknown filesystem type 'udf'
>>> mount: unknown filesystem type 'iso9660'
>>
>> For a CDROM, iso9660 is usually appropriate. Are you sure that that 
>> module is already loaded in the hardware node? A lot of distros leave 
>> iso9660 as a module and VEs cannot load kernel modules.
>>
>> Do a "modprobe iso9660" in the HN, to ensure that the module is 
>> loaded. Then try mounting the CD in the VE.
>
> modprobe iso9660 seems to work on the hardware node, however lsmod | 
> grep iso shown only
> isofs                  21348  0
>
> (which my googling suggests may actually me the right thing to see.)
>
> nevertheless, I can
> mount -t iso9660 /dev/hdc /media/cdrom0
> whereapon I get
> mount: block device /dev/hdc is write-protected, mounting read-only
> and df, in part, reports
> /dev/hdc                   458       458         0 100% /media/cdrom0
> /etc/fstab on the HN contains:
> /dev/hdc /media/cdrom0 udf,iso9660 user,noauto 0 0
>
> I then umount /dev/hdc and go into the ve (which has access to hdc via 
> vzctl set $1 --devnodes hdc:rw --save)
> it's /etc/fstab looks like this:
> # UNCONFIGURED FSTAB FOR BASE SYSTEM
> /dev/hdc /media/cdrom0 udf,iso9660 user,noauto 0 0
> if I do this:
> mount -t iso9660 /dev/hdc /media/cdrom0
> I get this:
> mount: unknown filesystem type 'iso9660'
>
>
>
>>
>>
> _______________________________________________
> Users mailing list
> Users at openvz.org
> https://openvz.org/mailman/listinfo/users