首页
学习
活动
专区
圈层
工具
发布
    • 综合排序
    • 最热优先
    • 最新优先
    时间不限
  • 来自专栏LinXunFeng的专栏

    解决fatal: The remote end hung up unexpectedly

    报错如图所示 解决方案 打开终端,进入到你的工程根目录下,打入命令 git config http.postBuffer 524288000 再重新 pod install 就可以了 命令作用:调整

    84550发布于 2018-06-29
  • 来自专栏*坤的Blog

    The remote end hung up unexpectedly

    ---- layout: default title: The remote end hung up unexpectedly category: [技术, git] comments: true --- fatal: The remote end hung up unexpectedly 上传一份代码的时候,出现了这个错误,然后就没有成功上传. Compressing objects: 100% (20587/20587), done. efatal: The remote end hung up unexpecterror: RPC failed Total 61350 (delta 39636), reused 59367 (delta 37653) fatal: The remote end hung up unexpectedly Everything 参考的博客 Git中push时出现错误fatal: The remote end hung up unexpectedly - 行者小朱的博客 - CSDN博客 http://blog.csdn.net

    2.9K50发布于 2018-06-04
  • 来自专栏devops_k8s

    一次内核hung task分析

    1 简介 今天发现突然有一台主机无缘无故死机了,于是翻看了/var/log/message日志,发现提示: echo 0 > /proc/sys/kernel/hung_task_timeout_secs 内核针对这种开发了一种hung task的检测机制,基本原理是:定时检测系统中处于D状态的进程,如果其处于D状态的时间超过了指定时间(默认120s,可以配置),则打印相关堆栈信息,也可以通过proc参数配置使其直接 同时需要向业务进程发送信号使其终止运行,业务进程在处理信号,退出过程中,需要等coredump搜集完成,从而一直处于D状态,而因为业务进程占用的内存比较大导致收集时间比较长,超过了2分钟,所以出现了阻塞,触发hung

    4.7K21发布于 2021-10-10
  • 来自专栏Linux问题笔记

    ext4 io hung模拟脚本

    /proc/sys/kernel/hung_task_panic 和 /proc/sys/kernel/nmi_watchdog 为0(这里如果不为0,内核会对长期占有CPU的进程做检查,如果有进程长期占用

    1.5K10编辑于 2022-10-31
  • 来自专栏开源部署

    解决Gitlab的The remote end hung up unexpectedly错误

    fatal: The remote end hung up unexpectedly fatal: early EOF fatal: unpack-objects failed 使用git clone重新

    1.2K10编辑于 2022-07-03
  • 来自专栏明明如月的技术专栏

    git fatal: The remote end hung up unexpectedly 错误

    . error: RPC failed; curl 56 OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 10054 fatal: The remote end hung Total 161 (delta 20), reused 0 (delta 0) fatal: The remote end hung up unexpectedly Everything up-to-date git config http.postBuffer 524288000 参见:https://stackoverflow.com/questions/6842687/the-remote-end-hung-up-unexpectedly-while-git-cloning

    2.2K20发布于 2021-08-27
  • 来自专栏笔记+

    crash分析rw_semaphore引发的系统hung问题

    该问题发生于centos7内核3.10.0-693.1.1.el7.x86_64,源码部分分析也来自该版本内核。

    3.3K110发布于 2020-05-09
  • 来自专栏雨夜-Elasticsearch成长专栏

    NFSv4客户端hung住的BUG,您解决了吗?

    ,昨天有几台物理机突然说需要升级内核,升级原因为 Redhat 7.4 kernel介于3.10.0-693.el7和3.10.0-693.5.2.el7,可能会因为nfs4 client 而导致主机hung 问题 在更新到REL7.4的内核后,NFS4.1客户端hung住了,在nfs_reap_expired_delegations里面的NFS4状态管理进程和一个tcpdump显示不断有相同状态id的TEST_STATEID 发送,和一个NFS4ERR_BAD_STATEID响应; 使用NFS4.1的NFS客户端,更新到REL7.4后,进程被hung或者产生hung主任务的错误信息。 55 48 89 e5 41 55 4c 8d af 综上原因为: RHEL7.4: NFS4状态管理线程卡在nfs_reap_expired_delegations无限循环中,导致NFS4客户端hung

    6.1K10发布于 2021-03-23
  • 来自专栏笔记+

    crash工具分析一个IO hung panic实例

    文章介绍: 本文主要介绍如何通过crash来分析系统IO hung导致的panic问题, 中间会穿插讲到一些mq-deadline调度器相关的关键数据结构。 1. sysctl_hung_task_timeout_secs = $4 = 120 crash> p sysctl_hung_task_panic sysctl_hung_task_panic = $5 = 1 crash> hung_task_timeout_secs配置的是120秒,也就是进程56149已经因为等待mutex锁而连续hung住120秒,因此可以推测出最近120秒内这个mutex 用一个图来描述整个问题触发的逻辑,虚线代表预期的响应逻辑: image.png 这个我前面已经分析清楚问题原因了,然后又不想关闭kernel.hung_task_panic那么怎么来解决呢? task监控任务超时时间: echo kernel.hung_task_timeout_secs = 480 >> /etc/sysctl.conf 4.

    5K112编辑于 2021-12-24
  • 来自专栏hbbliyong

    解决Git 克隆代码 The remote end hung up unexpectedly错误

    git config --global http.postBuffer 524288000

    3.8K10发布于 2019-12-12
  • 来自专栏爱可生开源社区

    故障分析 | 一则 MySQL 从节点 hung 死问题分析

    本文关键字:#MySQL# #复制# #Hung#

    65210编辑于 2024-04-11
  • 来自专栏10km的专栏

    解决git错误: error object file is empty , The remote end hung up unexpectedly

    (stored in .git/objects/88/526655aa4eca14ead2d443e80082276a79e0c2) is corrupt fatal: The remote end hung

    4.3K21发布于 2019-05-25
  • 来自专栏JiekeXu之路

    苦恼的数据库主机重启问题排查与解决

    这里就要说明下为何夯 120 秒主机就会重启,因为配置了操作系统参数 kernel.hung_task_panic = 1 导致主机重启了。 如果要关闭 hung task panic,则可以设置内核参数 kernel.hung_task_panic=0 进行关闭。所以这里呢我也就将这个参数注释掉,默认值就是 0。 [root@oracle19c ~]# sysctl -a | grep hung kernel.hung_task_check_count = 4194304 // khungtaskd 一次检测的最大线程数 kernel.hung_task_panic = 0 //是否将 hung task 检测结果转为panic kernel.hung_task_timeout_secs = 120 //khungtaskd 两次检测的最大 timeout时间 kernel.hung_task_warnings = 10 //hung task警告信息的发送次数。

    1.5K61编辑于 2023-02-24
  • 来自专栏公众号:咻咻ing

    GitHub代码总是拉取失败,本文的解决方法可以帮到你

    error: RPC failed; curl 56 LibreSSL SSL_read: SSL_ERROR_SYSCALL, errno 60 fatal: The remote end hung 54 error: RPC failed; curl 56 LibreSSL SSL_read: SSL_ERROR_SYSCALL, errno 54 fatal: The remote end hung up unexpectedly fatal: The remote end hung up unexpectedly Everything up-to-date 【问题原因】 对于 errno 54 error: RPC failed; curl 18 transfer closed with outstanding read data remaining fatal: The remote end hung

    35.2K126发布于 2019-12-16
  • 来自专栏Linux问题笔记

    一个mutex引发的血案——3.10内核 mount -a hung住问题看到的ext4 lazyinit那些坑

    接到一个问题,反馈D3.16XLARGE256(24块3T本地sata数据盘)机型,3.10内核,在初始化mkfs后mount -a,概率触发mount hung住,需要很长时间(半天左右)才能完成所有盘的挂载

    2K60编辑于 2022-11-02
  • 来自专栏热爱IT

    使用git提交时报错:error: RPC failed; HTTP 413 curl 22 The requested URL returned error: 413 Request Entity

    HTTP 413 curl 22 The requested URL returned error: 413 Request Entity Too Large fatal: The remote end hung up unexpectedly fatal: The remote end hung up unexpectedly Everything up-to-date 问题在于用http提交有上传大小限制

    22.4K51发布于 2020-04-10
  • 来自专栏Cell的前端专栏

    hexo d 出错

    by 13.229.188.59 port 22 fatal: sha1 file '<stdout>' write error: Broken pipe fatal: The remote end hung by 13.229.188.59 port 22 fatal: sha1 file '<stdout>' write error: Broken pipe fatal: The remote end hung

    1.4K30编辑于 2022-02-25
  • 来自专栏数据库中间件

    数据库中间件DBLE学习(四) 学习配置wrapper.conf

    对错误的检测,它还包括: 检测JVM是否挂起 检测应用程序是否死锁 检测应用错误 检测内存泄露 响应JVM退出代码 更多详细的内容可以参考wrapper 检测挂起Hung的原理 今天我们来说下它是如何检测 Hung的。 如果在配置的时间段内(默认为30秒)未能响应,则wrapper确定其已经hung住。同时Wrapper还考虑了诸如整个系统负载之类的问题,以确保将误报率保持在最低水平。 [wrapper5.png] 如果守护进程在一定时间内没有收到wrapper ping包的返回,守护进程就会认为客户端hung了,就会下发重启指令。

    1.5K00发布于 2020-01-22
  • 来自专栏四火的唠叨

    Issue record: “No thread for socket” about Memcached

    took a snapshot (jstack -F -l 31636) for the stacks in JVM, finding that almost all the threads were hung took several snapshots in series again and got the same result — it seemed all the threads were being hung By then nothing could explain why all the threads were being hung reading from cache server.

    29620编辑于 2022-07-15
  • 来自专栏CSDN博客专家-小蓝枣的博客

    Git 技术篇 - GitHub克隆私有仓库方法,新主机绑定并同步github私有库实例演示

    0) error: RPC failed; curl 7 OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 10054 fatal: the remote end hung up unexpectedly fatal: the remote end hung up unexpectedly Everything up-to-date

    4.4K20发布于 2021-12-01
领券