Zclient update recv wait error 0 in 1

Join the conversation

You can post now and register later.

If you have an account, sign in now to post with your account.

(104: Connection reset by peer) while reading response header from upstream

Лог начал заполнятся с сегодняшнего дня (первое сентября), до этого, с прошлого раза нет ни одной записи. Ни каких изменений в настройки сервера внесено не было.

Я пробовал добавить в «etc/nginx/nginx.conf» параметр:

Это не помогло. Кроме этого, многое, что было найдено в интернете, тоже не помогло.

На всякий случай, моя конфигурация Nginx выглядит так:

Что в логе: «/var/log/php7.2-fpm.log»?

Для получения информации открыть: «/etc/php/7.2/fpm/php-fpm.conf», найти:

Такие строчки плодятся с бешенной скоростью.

Протестировал Nginx ( nginx -t ), получил предупреждение:

После перехода на PHP 7.3 ошибка: recv() failed (104: Connection reset by peer) while reading response header from upstream снова дала о себе знать, правки что выше, не помогли. За одни сутки, в логе можно найти до восьми записей, с данной ошибкой.

В интернете нашел совет: изменить значение fastcgi_read_timeout до 600 секунд:

Источник

iTuneDVR

Сайт-мотиватор ИТ исследований систем видеонаблюдения: DVR, NVR, IPC, NVS, PC+ПО

2042 восстановление по tftp

2042 восстановление по tftp

Сообщение komplex » 10 фев 2018, 19:00

Доброго времени суток.
Пытаюсь восстановить камеру 2042WD-I, не загружается но загрузчик есть.

U-Boot 3.1.6-116607 (Apr 3 2015-11:43:37)
boards:121712
Boot From: NAND 2048 RC SYS_CONFIG: 0x30064059 POC: 100
Cortex freq: 600000000iDSP freq: 216000000D
ram freq: 564000000Core freq: 216000000
AHB freq: 108000000APB freq: 54000000
UART freq: 24000000SD freq: 48000000
SDIO freq: 48000000SDXC freq: 48000000
Hit Ctrl+u to stop autoboot: 2

Hit Ctrl+u to stop autoboot: 1

Hit Ctrl+u to stop autoboot: 0
boot_mini_system:Get dtb failed’update’ is a ambiguous command!
Exec the shortest commandboot_mini_system:
Get dtb failednand booting . boot_mini_system:
Get dtb failed

HKVS # help
The following commands are supported:
r32 w32 adc boot erase help
reset setenv printenv saveenv show
tftpboot bootm crc killb readoob
updtb updateb upf update format
upbs ubi go mii dump mtest
memset fdt nand usbdl gpio tftp
ping sd
Use ‘help’ to get help on a specific command

Команду update не дает использовать,

HKVS # update
‘update’ is a ambiguous command!
Exec the shortest commandboot_mini_system:Get dtb failed

HKVS # help update
Help for ‘update’:
update digicap.dav

Пробовал команду upf

HKVS # help upf
Help for ‘upf’:update firmware, format and update (factory use)

HKVS # upf***** UPDATE START *****
MAC: c4:2f:90:2f:95:00TFTP from server 192.0.0.128; our IP address is 192.0.0.64
Filename: ‘mImage’
Load address: 0x02000000 tftp transfer block size is set to 512 bytesdo_tftp_load:bld_udp_recv wait DATA(block=1)
timeout!tries=3 failed!error: upm.(error: tftp.)!
update mini system [FAIL]!error: upf.
. UPDATE FAIL .

Просит mImage файл.

Т.е. получается комфнда update для обновления фалом digicap не доступна,
команды u и upf просят файл mImage.

Кто сталкивался с такой ситуацией? Хелп.

Пытался разобрать прошивку R6 с помощью hiktools в надежде найти mImage не вышло, не разбирается.

Источник

Как исправить ошибку «recv() failed (104: Connection reset by peer) 502» в php-fpm / nginx?

Здравствуйте. Имеется сервер fastvps.ru/dedicated тариф EX-4, установлена ОС Debian-70-wheezy-64. Крутится один основной сайт, на связке nginx и php-fpm. Если нагрузить сайт тестом Siege буквально 10 потоками, то в лог начинают валиться ошибки:

readv() failed (104: Connection reset by peer) while reading upstream
recv() failed (104: Connection reset by peer) while reading response

Optcache включен. Помогите разобраться, что не так с конфигами? Судя по всему, дело в php-fpm.

• Вопрос задан более трёх лет назад
• 36524 просмотра

Оценить 1 комментарий

Siege разорвал соединение, пока nginx получал данные от php-fpm или что там у тебя в /etc/nginx/conf.d/*.conf;

Начни с тестов без php, сделай каталог с простым index.html и натрави туда. Если ошибки остались, дело в кол-во обработчиков: 4 процесса по 768 медленнее, чем 1 процесс с 3072 сокетами на современном железе. Подними worker_connections до 2048 хотя бы.

Далее с backlog
Через sysctl net.core.somaxconn узнай значение backlog, если оно меньше параметра worker_connections то в sysctl.conf увеличивай до значения = worker_connections
Такое же значение укажи в fpm listen.backlog

128 даже для дома, для торрентов маловато бывает. Для сайта конечно поднимай, 4096 смело можно ставить. worker_processes для тестов оставляй 4, но потом ставь 1 и мониторь макс кол-во соединений на 80 порт в секунду. Когда будет в 75% от (worker_connections*worker_processes) поднимешь worker_processes на единицу. Чем меньше worker_processes тем быстрее будет ответ от сервера (вообще там ищется золотая середина под железо и нагрузки на каждый час суток).

Скажи значение Response time в Siege. И включи slowlog с таймером равным значению Response time округлённый в большую сторону (будет в секундах «s», я надеюсь). Этим попытаемся определить какой скрипт тормозит.
Так же полезно будет знать нагрузку на проц и файловую систему (top, htop, iotop, bwm-ng)

В режиме перекомпиляции шаблонов response time 0.36s, число failed 10-15% от общего числа хитов. В боевом режиме без перекомпиляции 0.28s. Число failed = 0. Тестирую с домашнего компьютера, не локально то есть. Не знаю как скорость моего домашнего интернета влияет на repsonse time, но сама генерация внутри php занимает в среднем 0.05 — 0.08s, скрипты легкие, этот показатель давно уже мониторю.

Есть у меня одна мысль. В режиме перекомпиляции, каждый раз происходит opcache_reset(), что приводит к пересборке сайта я так понимаю и грузит файловую систему.

Прогнал iotop, в режиме перекомпиляции активность php-fpm от 1% вплоть до 20%. Это нормально? Каждое обращение порядка 10 файлов-шаблонов пишет/читает. В боевом режиме активность десятые проценты.

Т.е. судя по всему, в боевом режиме если поток людей будет очень большим, 502 ошибку по причине нагрузки на запись в диск я врятли увижу?

Источник

Unhandled communication error. Error: Could not write eeprom to sd card — no sd card mounted #259

Hi,
I’ve been running an older version of the 0.92 for years without issues, a week ago I upgraded the extruder with a v6 and flashed the latest 0.92.10 , I’ve been getting the following error: «Unhandled communication error. Error: Could not write eeprom to sd card — no sd card mounted» It happens at random times and when happening during a print job, the printer stops responding. I am not sure what this is about. Any help would be appreciated it.
I can also provide more information if needed. I have attached a screenshot. Thank you in advance!
https://www.dropbox.com/s/0bmke4qympjp14u/Image%20319.jpg?dl=0

The error message pops up when running octoprint / octopi. I contact the octoprint community and they told me is should have something to do with the repetier firmware which make sense since I haven’t done anything with octoprint but I did flashed rhe latest version of Repetier-Firmware-0.92 on my Da Vinci.

The text was updated successfully, but these errors were encountered:

Just wanted to add, I found a pattern, I get the error at the end of every print.
This is what shows up on the Terminal,

Recv: Info:Case lights off
Recv: wait
Send: N29998 M10536
Recv: ok 29998
Recv: T:208.28 / 0 B:40.97 / 0 B@:0 @:0
Recv: wait
Recv: wait
Recv: wait
Recv: wait
Send: N29999 M10537
Recv: ok 29999
Recv: T:201.78 / 0 B:40.84 / 0 B@:0 @:0
Recv: Error:Could not write eeprom to sd card — no sd card mounted
Changing monitoring state from ‘Operational’ to ‘Error: Could not write eeprom to sd card — no sd card mountedx0dx0a’
Recv: wait
Recv: wait

I never saw this error — did you tried to revert previous version to confirm issue follow firmware and it is not a bad luck ?

What was the working version ?

Can you share your end GCODE ? if it is only at the end of the print job and not during print, it means some command is messing up with FW, so should be part of end GCODE

The code I’ve attached, I’ve use it probably 20 times with the previous 0.92 firmware without issues.
To answer your question about the working version, I never paid attention to the build and now it’s gone since I’ve upgraded to 0.92.10, what I can tell you I installed 0.92 around May 2015 (whatever 0.92 build was around that time is what I’ve been running without issues until last week’s flash upgrade).
To add some more info, the issue happened with older GCODEs I have saved and new GCODES I downloaded recently and sliced them as well.

GCODE (this is
the the one I have saved and used multiple times in the past without issues and now gave me the error code at the end of the print with the new firmware) https://www.dropbox.com/s/68ynly1gj736jcl/Solo_Legs_Short_x5_Center_S.gcode?dl=0

I do not see anything wrong in end GCODE but anything could be wrongly interpreted by FW even some comment.

to narrow down and eliminate hw issue can you :
1 — try print same code but remove all comments at the end and remove the light off command, that may try to update EEPROM when it should not
2 — reverte to previous versio https://github.com/luc-github/Repetier-Firmware-0.92/releases/tag/v0.92.3.0

One difference between 92.3 and 0.92.10 is : virtual EEPROM is now managed by repetier code and writing update cycle are different

Thank you for the quick response,
1 — I just removed the end code and I am printing a test to see how it goes.
2 — I would definitely try 92.3 and report back.

1- Removing the end code didn’t make a different.
2- Flashed 92.3 and the issue is gone!!
Now, if the issue is with the EEPROM being managed by repetier, is there anything I can do to run the latest firmware 92.10 or I shouldn’t be concerned of keeping 92.3.
Just wondering if I am missing something by running an older firmware.
Thanks a lot!!

0.92.10 has several bug fixes including a working autolevel according to repetier and support multilanguage at runtime

here some test you can do :
1 — try to print from SD instead of host
2 — if issue happen, without reseting anything, check if printer can list SDfiles from printer menu using print files, and also if printer answer properly with M20 command from Host
3 — if nothing works in 2 send M21 command to init SD and retry 2

this will help to see if somehow SD card is released or if SD card is loose and removed

what is your printer model ? it use standard SD or Micro SD ?

I have a Da Vinci 1.0a, I thought I couldn’t use the SD, since it’s glue to the motherboard. And I am using Octopi on a Raspberry Pi.

glue can be removed — several people did it
if you cannot print from SD then print as usual and send commands I have listed after error happen from octopi web interface

Yes, commands don’t fix the problem.
After every print I get the same SD Eeprom message, have to refresh octoprint and reconnect every time on 92.10

but what are the results of the commands ?

oh, sorry, I didn’t take the output. I will paste it soon.

Just tried to send commands over the terminal after disconnect, not possible. Octoprint terminal won’t let me send commands unless I refresh the browser and re-connect by clicking the connect button on the portal.
After getting re-connected I can send the two commands but is useless at this point since I am connect it already.

I do not get, the issue is on accessing EEPROM or accessing printer ?

When a print is finished, the printer gets disconnected from Octoprint and on the terminal displays the EEPROM message. I also noticed if I am browsing the printer’s menu and hit the Home button, it also disconnects from Octoprint displaying the same eeprom sd message.
This behavior does not occur with the older version of Repetier 92.3
Sorry, I am not an expert on coding, I am just trying to explain what has been going on with my printer since I’ve upgraded to Repetier 92.10.
Maybe this is just a behavior between Repetier 92.10 and Octoprint and I will have to live with it. The one thing I know, the Octoprint developer pointed me to the Repetier firmware and is why I started the thread over here.

disconnecting and error accessing EEprom on SD card are 2 differents problems
I do not think disconnection is an big issue as you can reconnect after print is done, right ?

also did you applied the USBcore.cpp on 0.92.3 and on 0.92.10 ?

I followed the instructions https://github.com/luc-github/Repetier-Firmware-0.92
There is no mentioned of the USBcore.cpp file.
Anyways, I did flashed once without copying the above file and another one with the USBcore.cpp. Same results.

hum just checked seems there were some glitch when I merged latest version — readme is broken and miss USBCore.cpp reference — fixed

Back to EEPROM issue — Can you get commands result when reconnecting after issue happen ? you mentioned that you must reconnect but you did not share commands result

any update on this ?

The one update I have is that I found out another user with similar setup has the exact same problem.

I do not said there is no issue — I just cannot reproduce it so no idea how to investigate
as wrote before :
Can you get commands result when reconnecting after issue happen ? you mentioned that you must reconnect but you did not share commands result

Started a print, after the print finished, printer disconnects and get the «unhanded communication error» on the Octoprint portal.
Output from terminal below

Recv: Printed filament:1.59m Printing time:0 days 0 hours 22 min
Recv: ok 20832
Send: N20833 M140 S0111
Recv: ok 20833
Send: N20834 M8418
Recv: ok 20834
Send: N20835 M10741
Recv: ok 20835
Changing monitoring state from ‘Printing’ to ‘Operational’
Recv: Unknown command:N20835 M107
Send: N20836 M10540
Recv: ok 20836
Recv: T:229.29 / 0 B:29.36 / 0 B@:0 @:0
Recv: wait
Recv: wait
Recv: wait
Recv: wait
Send: N20837 M10541
Recv: ok 20837
Recv: T:229.01 / 0 B:29.63 / 0 B@:0 @:0
Recv: wait
Recv: wait
Recv: wait
Recv: wait
Send: N20838 M10538
Recv: ok 20838
Recv: T:224.22 / 0 B:29.36 / 0 B@:0 @:0
Recv: wait
Recv: wait
Recv: wait
Recv: wait
Recv: Error:Could not write eeprom to sd card — no sd card mounted
Changing monitoring state from ‘Operational’ to ‘Error: Could not write eeprom to sd card — no sd card mounted
‘
Recv: wait
Recv: wait
Recv: wait
Recv: wait
Recv: wait
Recv: wait
Recv: wait

I have no choice but to manually reconnect, on Octoprint I have to click on «Connect» under Connection
Output from terminal below

Источник

Need help to fix Zimbra ERROR zclient IO ERROR? We can help you.

As part of our Server Management Services, we help our customers with similar errors regularly.

Today, let’s see how our Support Engineers tackle this.

Zimbra ERROR zclient IO ERROR

When we get the following error:

[] INFO: I/O exception (java.net.ConnectException) caught when processing request: Connection refused
[] INFO: Retrying request
ERROR: zclient.IO_ERROR (invoke Connection refused, server: localhost) (cause: java.net.ConnectException Connection refused)

we cannot execute any Zimbra zmprov commands. This is devastating since Zimbra Admin users use Zimbra CLI a lot.

In this article, let us see how our Support Engineers fix the error.

What is Zimbra zmprov?

The zmprov tool performs all provisioning tasks in Zimbra LDAP. It includes, creating accounts, aliases, domains, COS, distribution lists, and calendar resources.

Generally, each operation is invoked through the command-line options, each of which has a long name and a short name.

What causes the error

The major cause of this error is when Zimbra zmprov is not configured to get results from LDAP. To fix this, we need to set zimbra_zmprov_default_to_ldap to TRUE.

This will make sure all the zmprov commands get replies from LDAP server.

How to fix Zimbra ERROR zclient IO ERROR

• We do a checking for the setting of zimbra_zmprov_default_to_ldap to be sure.

$ zmlocalconfig |grep zmprov
zimbra_zmprov_default_soap_server = localhost
zimbra_zmprov_default_to_ldap = false
zmprov_safeguarded_attrs = zimbraServiceEnabled,zimbraServiceInstalled
zmprov_tmp_directory = ${zimbra_tmp_directory}/zmprov

• If set to false, we reconfigure it to have the true flag. This will enable the setting.

$ zmlocalconfig -e zimbra_zmprov_default_to_ldap=true

• Then we recheck the settings:

$ zmlocalconfig |grep zmprov
zimbra_zmprov_default_soap_server = localhost
zimbra_zmprov_default_to_ldap = true
zmprov_safeguarded_attrs = zimbraServiceEnabled,zimbraServiceInstalled
zmprov_tmp_directory = ${zimbra_tmp_directory}/zmprov

• Now we try to execute any zmprov commands and see if it’s working fine.

$ zmprov gs `zmhostname` | grep zimbraServiceEnabled
zimbraServiceEnabled: amavis
zimbraServiceEnabled: antivirus
zimbraServiceEnabled: antispam
zimbraServiceEnabled: opendkim
zimbraServiceEnabled: stats
zimbraServiceEnabled: logger
zimbraServiceEnabled: proxy
zimbraServiceEnabled: service
zimbraServiceEnabled: zimbra
zimbraServiceEnabled: zimbraAdmin
zimbraServiceEnabled: zimlet
zimbraServiceEnabled: mailbox
zimbraServiceEnabled: spell
zimbraServiceEnabled: ldap
zimbraServiceEnabled: memcached
zimbraServiceEnabled: mta
zimbraServiceEnabled: snmp
zimbraServiceEnabled: dnscache

If this does not solve the problem, we try changing the zimbra_zmprov_default_soap_server to the IP address of our Mailbox server.

The setting will look like this.

$ zmlocalconfig -e zimbra_zmprov_default_soap_server=ip-address

• We have to execute the command using ‘zmprov -l’ instead of just ‘zmprov’ until mailboxd is running again. This will directly query the ldap server.

[Still stuck with the error? We are happy to assist.]

Conclusion

To conclude, the error can prevent us from executing any Zimbra zmprov commands. Today, we saw how our Support Engineers go about to fix this error.

var google_conversion_label = «owonCMyG5nEQ0aD71QM»;