“ongepast ioctl voor apparaat”

Ik heb een Perl-script in een AIX-box.

Het script probeert een bestand uit een bepaalde map te openen en het kan het bestand niet lezen omdat het bestand geen leesrechten heeft, maar ik krijg een andere foutmelding met de melding inappropriate ioctl for device.

Moet er niet iets in staan als no read permissions for fileof iets dergelijks?

Wat betekent dit inappropriate ioctl for device-bericht?

Hoe kan ik dit oplossen?

EDIT: Dit is wat ik vond toen ik stracedeed.

open("/local/logs/xxx/xxxxServer.log", O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE,
  0666) = 4 _llseek(4, 0, [77146], SEEK_END) = 0
ioctl(4, SNDCTL_TMR_TIMEBASE of TCGETS, 0xbffc14f8) = -1 ENOTTY
  (Ongepast ioctl voor apparaat)

Antwoord 1, autoriteit 100%

Hoogstwaarschijnlijk betekent dit dat de open niet mislukte.

Als Perl een bestand opent, controleert het of het een TTY is (zodat het de -T $fhfiletest-operator kan beantwoorden) door de TCGETSioctl tegen. Als het bestand een normaal bestand is en geen tty, mislukt de ioctl en stelt errno in op ENOTTY(tekenreekswaarde: “Ongepaste ioctl voor apparaat”). Zoals ysth zegt, is de meest voorkomende reden voor het zien van een onverwachte waarde in $!het controleren wanneer het niet geldig is — dat wil zeggen overal andersdan direct nadat een syscall is mislukt , dus het testen van de resultaatcodes van uw bewerkingen is van cruciaal belang.

Als openinderdaad false voor u retourneerde, en u vond ENOTTYin $!, dan zou ik dit als een kleine bug beschouwen (waardoor een nutteloze waarde van $!) maar ik zou ook erg benieuwd zijn hoe het is gebeurd. Code en/of truss-uitvoer zou handig zijn.


Antwoord 2, autoriteit 50%

oneven fouten zoals “ongepast ioctl voor apparaat” zijn meestal een resultaat van het controleren van $! Op een bepaald punt anders dan net nadat een systeemoproep is mislukt. Als u uw code zou laten zien, wed dat iemand snel zou optreden op uw fout.


Antwoord 3, Autoriteit 17%

“Ongepaste IOCTL voor Apparaat” is de foutkoord voor de enotty-fout. Het werd voornamelijk door de voornamelijk door pogingen om terminal-eigenschappen te configureren (bijvoorbeeld echo-modus) op een bestandsdescriptor die geen terminal was (maar zeg, een normaal bestand), vandaar entty. Meer in het algemeen wordt het geactiveerd bij het doen van een IOCTL op een apparaat dat niet ondersteunt dat IOCTL, vandaar de foutkoord.

Om erachter te komen wat IOCTL wordt gemaakt die mislukt, en op welke bestandsdescriptor, voert u het script uit onder strace / truss. U herkent Enotty, gevolgd door het daadwerkelijke afdrukken van het foutbericht. Zoek vervolgens naar welk bestandsnummer werd gebruikt en welk open () oproep heeft dat bestandsnummer geretourneerd.


Antwoord 4, Autoriteit 13%

“bestanden” in * NIX-type systemen zijn veel een abstract concept.

Ze kunnen gebieden op schijf zijn georganiseerd door een bestandssysteem, maar ze konden even goed een netwerkverbinding zijn, een beetje gedeeld geheugen, de bufferuitgang van een ander proces, een scherm of een toetsenbord.

Om Perl echt nuttig te zijn, spiegelt het dit model zeer nauw en behandelt geen bestanden door een magnetische band te emuleren, maar ook zoveel 4GLS.

Dus het probeerde een “IOCTL” -operatie ‘open voor schrijven’ in een bestandshandvat waarmee schrijfbewerkingen geen ongepaste IOCTL-werking voor dat apparaat / bestand is.

Het gemakkelijkste om te doen is een “or die 'Cannot open $myfile'verklaring aan het einde van u openen en u kunt uw eigen betekenisvolle boodschap kiezen.


Antwoord 5, Autoriteit 13%

Aangezien dit een fatale fout is en ook vrij moeilijk te debuggen, kan de oplossing misschien ergens worden geplaatst (in de opgegeven opdrachtregel?):

export GPG_TTY=$(tty)

Van: https://github.com/keybase/keybase-issues/issues/ 2798


Antwoord 6, autoriteit 9%

Ik heb zojuist deze perl-bug opgelost.
Zie https://rt.perl.org/Ticket/Display.html?id= 124232

Als we de bufferlaag naar PerlIO pushen en een mislukte isatty()-controle uitvoeren
die uiteraard faalt op alle normale bestanden, negeer de verkeerde errno ENOTTY.


Antwoord 7, autoriteit 4%

Eureka-moment!

Ik heb deze fout eerder gehad.

Heb je de perl debugger aangeroepen met zoiets als:-

perl -d yourprog.pl > log.txt

Als dat zo is, probeert perl debug een query uit te voeren en misschien de breedte van de terminal opnieuw in te stellen.
Als stdout geen terminal is, mislukt dit met het IOCTL-bericht.

Het alternatief zou zijn dat uw foutopsporingssessie voor altijd vastloopt omdat u de prompt voor instructies niet hebt gezien.


Antwoord 8

Vandaag deze fout tegengekomen toen ik code probeerde te gebruiken om een map/bestanden te verwijderen die op een Windoze 7-box staan die als een share op een Centos-server is aangekoppeld. Kreeg de ongepaste icotl voor apparaatfout en probeerde alles wat in me opkwam. Lees zowat elke post op het net die hiermee verband houdt.

Het probleem was duidelijk te wijten aan de aangekoppelde Windoze-share op de Linux-server. keek
bij de bestandsrechten op de Windoze-box en merkte op dat de rechten voor de bestanden waren ingesteld op alleen-lezen.

Veranderd, ging terug naar de Linux-server en alles werkte zoals verwacht. Dit is misschien niet de oplossing voor de meesten, maar hopelijk bespaart het iemand wat tijd.


Antwoord 9

Ik heb de volgende code geprobeerd die leek te werken:

if(open(my $FILE, "<File.txt")) {
    while(<$FILE>){
    print "$_";}
} else {
    print "File could not be opened or did not exists\n";
}

Antwoord 10

Ik krijg de foutmelding Can't open file for reading. Inappropriate ioctl for deviceonlangs toen ik een oud UB2K-forum met een DBM-bestandsdatabase migreerde naar een nieuwe host. Blijkbaar zijn er meerdere, incompatibele implementaties van DBM. Ik had een back-up van de database, dus ik kon die laden, maar het lijkt erop dat er andere opties zijn, b.v. een perl-script/dbm naar een nieuwe server verplaatsen en dbm verlaten?.

Other episodes