Linux bad file number

why it can be «bad file number» when i write to socket

I have a problem with sending message to server socket from client. write function returns error — bad file number. It means that I haven’t permission to write to this socket. But from another client I can write to this socket, and do it successfully. Most interesting, that when another client connected to server my(problem) client can send message too. the code of my client:

SOCKET OnceCommand; struct sockaddr_in SAddress4; struct autoC < char buf[4]; short fromx; short fromy; short tox; short toy; char step; char cycle; >; union autocomm < char byte[14]; struct autoC command; >Command1, Command2; memset(&SAddress4,0,sizeof(SAddress4)); SAddress4.sin_family = AF_INET; SAddress4.sin_port = htons(444); SAddress4.sin_addr.s_addr = inet_addr(RobotsIP[Robot1]); memset(&(SAddress4.sin_zero),0,8); if((OnceCommand = socket(AF_INET,SOCK_STREAM,0))!=SOCKET_ERROR) < Err(OnceCommand); if(conn = connect(OnceCommand,(struct sockaddr *)&SAddress4,sizeof(struct sockaddr))!=SOCKET_ERROR) < rc = write(OnceCommand,(char*)Command1.byte,sizeof(Command1.byte)); if(rc < 0) < perror("Client-write() error"); rc = getsockopt(OnceCommand, SOL_SOCKET, SO_ERROR, &temp, &length); if(rc == 0) < Err(OnceCommand); perror("SO_ERROR was"); >closesocket(OnceCommand); > else < adv_printf("Client-write() is OK\n"); adv_printf("String successfully sent lol!\n"); >shutdown(OnceCommand,2); closesocket(OnceCommand); > > 

in SO_ERROR was «bad file number» I’m using sockets lib in ADAM-5510 microcontroller based with ROM-DOS. I tried to solve this problem by using NONBLOCKing sockets, but select returns only read ready flag.

Источник

ТЕМА: initrd failed: bad file number

initrd failed: bad file number 20 Апр 2016 13:19 #3642

Всем доброго времени суток.
Возникла проблема при запуске тонкого клиента по сети.
Проблема звучит так: «::/boot/initrd failed: Bad file number» Что с этим делать, как решать, какие настройки поменять?

Теперь опишу что у меня есть.
ВVirtualBox создал две машины, СЕРВЕР — Windows Server 2012 R2 Datacenter, КЛИЕНТ — Other/unknown(64-bit)
Настройки сервера:
1. Стоит Ttftpd64, работает только как tftp сервер. Каталог загрузки «С:\tftpboot». В этом каталоге лежит PXE
2. Настройки DHCP:
Пул адресов 10.0.2.100 — 10.0.2.254;
Параметры области (006 DNS-серверы 10.0.2.2)
(012 имя узла dyn.dhcp.test)
(066 имя узла сервера загрузки 10.0.2.2)
(067 имя файла загрузки «boot/pxelinux/pxelinux.0»)
Политики Класс BOOTP по умолчанию — отключен

В реестре Windows в ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\WDSServer\Providers\WDSTFTP добавил параметр
RootFolder = «C:\TFTPBOOT»
Изменил содержимое параметра ReadFilter на \*

При запуске клиента происходит следующее (снимок экрана):

Сам файл initrd лежит в папке «c:\tftpboot\boot\» на всякий случай разместил его и в корне «c:\tftpboot\»

Так же прикреплю файл с логом из TFTPD64 (что бы не спамить лишним текстом в теме/вопросе)

P.S. образ thinstation который использую — работает на другом сервере (реальном не виртуальном) стабильно без проблем.

Источник

git Bad file number

I’ve been trying to git archive a new version of the system I’m currently working on, but, suddenly, the git archive command, which I used to use, stopped working. I use the git archive followed by the git diff + filters , that is necessary only to get the diff between the tagged versions. Right now, I can’t generate the archive (a zip package) containing the version changes because of this error: sh.exe»: /bin/git: Bad file number I tried the git diff + filters (ACMRT and stuff) and it shows me the correct diff, so, I discarted the problem with the diff. Later, I tried the `git archive only, with a test file, and it worked aswell. But if I use both together, it gives me the error. Have anyone seen anything like this? Thanks!

Which Os (Linux I presume) and git version are you using? I always see that message Bad file number in relation with connection issues (ssh mostly or https). I have only see it in a different contaxt once: git.661346.n2.nabble.com/Challenge-with-Git-Bash-td5306355.html

@VonC still the same issue. As far as I remember, I also upgraded to 1.8.3 thinking that maybe the bug could be solved (if it’s even a bug, idk). I’ve checked the commited files (afaik the files should not have empty spaces in its names), corrupted files, folders, and stuff, and I found nothing weird.

Quite strange. Any chance to reset the process with a full archive, and see if future archive+diff work better, starting after that new full archive?

Источник