Linux no data available

Linux — ioctl with FIONREAD always 0

I’m trying to get to know how many bytes there are readable at my TCP socket. I am calling ioctl with the Flag «FIONREAD» which should actually give me this value. When I call the function I get as return val 0 ( so no Error ) but also my integer argument gets the value 0. That would be no problem but when I call the recv() method I actually read some Bytes out of the socket. What am I doing wrong? // here some Code:

char recBuffer[BUFFERLENGTH] = ; int bytesAv = 0; int bytesRead = 0; int flags = 0; if ( ioctl (m_Socket,FIONREAD,&bytesAv) < 0 ) < // Error >if ( bytesAv < 1 ) < // No Data Available >bytesRead = recv(m_Socket,recBuffer,BUFFERLENGTH,flags); 

4 Answers 4

It’s happening very quickly, that’s why you don’t see anything. What you’re doing:

• ioctl : Is there data for me ? No, nothing yet
• recv : Block until there is data for me. Some (short) time later: Here is your data

So if you really want to see FIONREAD , just wait for it.

/* Try FIONREAD until we get *something* or ioctl fails. */ while (!bytesAv && ioctl (m_Socket,FIONREAD,&bytesAv) >= 0) sleep(1); 

Works! Thank you! Worked even without the loop ( just give him to the time to get the data ^^ ) But I have another questio now.

I’m wondering, why nobody suggested to use poll() or epoll(). And after that to try to get the size of the data available for reading.

The real answer here is to use select(2) like cnicutar said. Toby, what you aren’t understanding is that you have a race condition. First you look at the socket and ask how many bytes are there. Then, while your code is processing the «no data here» block, bytes are being received by the hardware & OS asynchronous to your application. So, by the time that the recv() function is called, the answer of «no bytes are available» is no longer true.

if ( ioctl (m_Socket,FIONREAD,&bytesAv) < 0 ) < // Error >// BYTES MIGHT BE RECEIVED BY HARDWARE/OS HERE! if ( bytesAv < 1 ) // AND HERE! < // No Data Available // BUT BYTES MIGHT BE RECEIVED BY HARDWARE/OS HERE! >// AND MORE BYTES MIGHT BE RECEIVED BY HARDWARE/OS HERE! bytesRead = recv(m_Socket,recBuffer,BUFFERLENGTH,flags); // AND NOW bytesRead IS NOT EQUAL TO 0! 

Sure, a small sleep probably fixed your program two years ago, but it also taught you terrible coding practice and you lost out on an opportunity to learn how to use sockets correctly by using select().

Further, as Karoly Horvath said, you can tell recv to not read more bytes than you can store in the buffer that the user passed in. Then your function interface becomes «This fn will return as many bytes as are available on the socket, but not more than [buffer size you passed in]».

This means that this function doesn’t need to worry about clearing the buffer any more. The caller can call your function as many times as necessary to clear all of the bytes out of it (or you can provide a separate fn that discards the data wholesale and not tie up that functionality in any specific data gather function). Your function is more flexible by not doing too many things. You can then create a wrapper function that is smart to your data transfer needs of a particular application, and that fn calls the get_data fn and the clear_socket fn as needed for that specific app. Now you are building a library you can carry around from project to project, and maybe job to job if you’re so lucky as to have an employer that lets you take code with you.

Источник

lvm vgchange device-mapper reload ioctl on failed No data available

The RAID-5 (Linux Multiple Disks) has crashed and since the rebuild it cannot be activated anymore. What can I do. Some diagnostic output, tell me if you need more information:

[~] # pvs -v --segments Using physical volume(s) on command line. PV VG Fmt Attr PSize PFree Start SSize LV Start Type PE Ranges /dev/md1 vg1 lvm2 a-- 21.80t 0 0 36864 lv544 0 linear /dev/md1:0-36863 /dev/md1 vg1 lvm2 a-- 21.80t 0 36864 16384 tp1_meta6 0 linear /dev/md1:36864-53247 /dev/md1 vg1 lvm2 a-- 21.80t 0 53248 5662624 [tp1_tierdata_2_fcorig] 0 linear /dev/md1:53248-5715871 /dev/sdf vg1 lvm2 a-- 7.28t 6.78t 0 16384 tp1_meta1 0 linear /dev/sdf:0-16383 /dev/sdf vg1 lvm2 a-- 7.28t 6.78t 16384 16384 tp1_meta2 0 linear /dev/sdf:16384-32767 /dev/sdf vg1 lvm2 a-- 7.28t 6.78t 32768 16384 tp1_meta3 0 linear /dev/sdf:32768-49151 /dev/sdf vg1 lvm2 a-- 7.28t 6.78t 49152 16384 tp1_meta4 0 linear /dev/sdf:49152-65535 /dev/sdf vg1 lvm2 a-- 7.28t 6.78t 65536 16384 tp1_meta0 0 linear /dev/sdf:65536-81919 /dev/sdf vg1 lvm2 a-- 7.28t 6.78t 81920 16384 tp1_meta5 0 linear /dev/sdf:81920-98303 /dev/sdf vg1 lvm2 a-- 7.28t 6.78t 98304 16384 tp1_meta7 0 linear /dev/sdf:98304-114687 /dev/sdf vg1 lvm2 a-- 7.28t 6.78t 114688 16384 [tp1_tmeta] 0 linear /dev/sdf:114688-131071 /dev/sdf vg1 lvm2 a-- 7.28t 6.78t 131072 1776649 0 free [~] # vgs -v Using volume group(s) on command line. VG Attr Ext #PV #LV #SN VSize VFree VG UUID VProfile vg1 wz--n- 4.00m 2 12 0 29.08t 6.78t 1VJkVt-vfPX-vBAv-KtuC-kKDU-1CDd-1RBuel [~] # lvs -v Using logical volume(s) on command line. target_name:thin-pool LV VG #Seg Attr LSize Maj Min KMaj KMin Pool Origin Data% Meta% Move Cpy%Sync Log Convert LV UUID LProfile lv1 vg1 1 Vwi---t--- 21.00t -1 -1 -1 -1 tp1 TuCexj-MyZA-uIkX-kzVp-KBWt-dHVQ-Iq6t27 lv288 vg1 1 Vwi---t--- 2.00t -1 -1 -1 -1 tp1 f0jKvz-Jm4G-JZ8l-8ysp-2RDS-cDWJ-Ue0VCR lv544 vg1 1 -wi-a----- 144.00g -1 -1 252 0 SHXwIE-iAMG-5ctO-g0RG-55P9-jeke-df3S4n tp1 vg1 1 twi-aot--- 21.60t -1 -1 252 6 0.00 0.02 Hk25P5-gQkc-pJHw-jKfL-U9cB-2vBF-74lr2L tp1_meta0 vg1 1 -wi-a----- 64.00g -1 -1 252 8 foHo1k-gciB-VJcM-9CRV-ySC0-0I9A-rshk3A tp1_meta1 vg1 1 -wi-a----- 64.00g -1 -1 252 9 8bloJL-stWn-1O3r-j5jQ-vlqv-DpNe-waeIef tp1_meta2 vg1 1 -wi-a----- 64.00g -1 -1 252 10 AvXCmL-zVIg-xTCm-ZtOz-1VGT-EEBU-cugNA8 tp1_meta3 vg1 1 -wi-a----- 64.00g -1 -1 252 11 EVcMvv-S0BC-N0Xh-5Pzj-3Rrj-RkFb-ZTgMw8 tp1_meta4 vg1 1 -wi-a----- 64.00g -1 -1 252 12 YCgXIz-eZxy-N2Wz-8Exl-9dJw-syIb-dVeux4 tp1_meta5 vg1 1 -wi-a----- 64.00g -1 -1 252 13 H35ozg-XyJ3-rjPP-ipTz-DIDV-JNPA-fSg54E tp1_meta6 vg1 1 -wi-a----- 64.00g -1 -1 252 14 fl5ACi-7uNv-h5Fw-71NI-G8nT-93sz-VgMdR5 tp1_meta7 vg1 1 -wi-a----- 64.00g -1 -1 252 15 ap8Nds-GACe-9dXu-BZ6J-H1df-HwOc-pQ7VnX 

Источник

Thread: gvfs error. No Data Available.

Ubuntu addict and loving it

gvfs error. No Data Available.

Sometimes I get this error with .gvfs mounted CIFS shares:

Error: No data available
Please select another viewer and try again.

This is interrupting my backup procedure as there are times during the backup it just shuts off. When I click on my share, I get this error, which tells me something happened to the connection during the backup process. It also does this at times even if my system has been idle for a while and I click on the share to explore the data, which also suggests it’s not isolated to JUST when I run backups.

Does anybody know what I can do to fix it?

First Cup of Ubuntu

Re: gvfs error. No Data Available.

Sorry to resurrect an old thread, but I get this same error with my Western Digital My Book Live. Anyone ever stumble upon a fix or workaround?

Ubuntu addict and loving it

Re: gvfs error. No Data Available.

Oh man. I wish I had tagged more info in that thread when I posted it. I’m having zero issues now and have no idea how (if) I fixed it.

Can you give more information on your issue? Maybe it’ll help get my memory going.

Gee! These Aren’t Roasted!

Re: gvfs error. No Data Available.

As with others, I intermittently get a dialog box saying

Could not display «smb://user@host/share/».
Error: No data available
Please select another viewer and try again.

when clicking on a network share as listed on the left hand side in nautilus. Clicking OK to the dialog box and clicking on the share again then works. (In the actual message ‘user’, ‘host’ and ‘share’ are substituted with the correct information.)

Any explanation? fix? workaround?

I have six network shares and I think they all exhibit the same problem from time to time. Those shares are spread over two different servers (running two different distros i.e. not the same as each other and neither is Ubuntu, although one is Mint).

Gee! These Aren’t Roasted!

Re: gvfs error. No Data Available.

The shares that are on the server running Linux Mint get a different error

Error: invalid argument

and this seems to occur after coming out of Hibernation on the client (and perhaps only after that). So let’s ignore those ones here. It’s probably the same as e.g. https://bugs.launchpad.net/ubuntu/+s. fs/+bug/382555

The shares that are on the other server get the error that started this thread and this error occurs intermittently throughout the day.

Источник

LVM after vgcfgrestore got: device-mapper: reload ioctl on (254:19) failed: No data available

# vgcfgrestore --force --file /etc/lvm/archive/pve_00336-2034680334.vg pve # vgimport pve # lvchange -ay /dev/pve/vm-130-disk-0 Thin pool pve-data-tpool (254:6) transaction_id is 324, while expected 311. . # lvs -a LV VG Attr LSize Pool Origin Data% Meta% data pve twi---tz-- 1.57t # NOT activated pool data [data_tdata] pve Twi-a----- 1.57t # OK a=Activated [data_tmeta] pve ewi-a----- 16.00g # OK a=Activated root pve -wi-a----- 10.00g # OK a=Activated vm-130-disk-0 pve Vwi---tz-- 32.00g data # NOT activated deleted volume vm-137-disk-0 pve Vwi---tz-- 22.00g data # NOT activated non-deleted volume . 

Well, here we failed because transaction missmatch between tmeta and tpool. Most answered people in Internet have mirror situation: tpool=312 and tmeta=324 and looks like transaction_id fix in .vg file helps them. Let’s try to fix .vg file and activate:

Changed by hands transaction_id from 311 to 324 in /etc/lvm/archive/pve_00336-2034680334.vg .. # vgcfgrestore --force --file /etc/lvm/archive/pve_00336-2034680334.vg pve # vgimport pve # lvchange -ay /dev/pve/vm-130-disk-0 device-mapper: reload ioctl on (254:19) failed: No data available In debug log appears: pve-vm--130--disk--0: Skipping NODE_DEL [trust_udev] # lvs -a LV VG Attr LSize Pool Origin Data% Meta% data pve twi-aotz-- 1.57t 5.86 0.44 # OK [data_tdata] pve Twi-a----- 1.57t # OK [data_tmeta] pve ewi-a----- 16.00g # OK root pve -wi-a----- 10.00g # OK vm-130-disk-0 pve Vwi---tz-- 32.00g data # NOT activated deleted volume vm-137-disk-0 pve Vwi-a-tz-- 22.00g data 67.91 # OK activated non-deleted volume . 

«No data available» for deleted volume. Sad. AFAIK tpool has transaction_id=324 and I need somehow rollback tpool to 312. No idea how. What can I to activate pve/vm-130-disk-0 ?

# lvm version LVM version: 2.02.168(2) (2016-11-30) Library version: 1.02.137 (2016-11-30) Driver version: 4.35.0 # uname -a Linux adminslotlogicrestoreasap 4.9.0-11-amd64 #1 SMP Debian 4.9.189-3+deb9u2 (2019-11-11) x86_64 GNU/Linux 

Источник

Logrotate failing with `No data available` error

I’m using logrotate for various log rotation tasks, including rotating log files for the postgresql pooling utility pgbouncer . pgbouncer logs expansively — I accumulate many GBs in a couple of days — thus I changed its config in logrotate.d to size 100M and rotate 5 , hoping that this would limit pgbouncer’s logs to an aggregate of 500MB. I then ran logrotate -f /var/logrotate.conf to force the changes. The command took a good 10 minutes to give me output. The output was error writing to /var/log/postgresql/pgbouncer.log.1: No data available . I.e. rotation failed for pgbouncer. How do I fix this? Please advise. p.e. If I do tail -f pgbouncer.log , I see a ton of log lines being generated in real time, so logging is still going on. Moreover, pgbouncer.log.1 does not exist.

1 Answer 1

I didn’t have enough disk space for log rotation to actually create all the rotated log files dictated by my .conf file. I truncated the log file, tried again, and it worked.

You must log in to answer this question.

Related

Hot Network Questions

Subscribe to RSS

To subscribe to this RSS feed, copy and paste this URL into your RSS reader.

Site design / logo © 2023 Stack Exchange Inc; user contributions licensed under CC BY-SA . rev 2023.7.14.43533

By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.

Источник