为什么要反复地失去这个Armbian的连接呢？

Question

我有一个Olimex Lime2，运行一个无头的阿姆斯。在这个板上，我只关心SSH和MiniDLNA。我希望能够包括整个配置，但其中一个重要的部分可能是我在/boot/armbianEnv.txt中放置的

extraargs=acpi=off

一年来，我很难调试可用性方面的问题。机器随机停止，通过ping或ssh访问。这些问题很难调试，因为当连接监视器或键盘时，它们似乎消失了，而当系统无头运行时，我却找不到它们的任何踪迹。虽然我在不知道如何控制的情况下控制了这个问题，但Olimex仍然不时地停下来回应。这一次我想问为什么。

我注意到Olimex在10/25~下午2点停止提供DLNA接入。我没有碰它看它是否恢复了(有时会这样)。这一次，系统一直无法到达2天，直到我拔出电源。

下面可以找到两个日志的链接。如果能指出其中任何可疑之处，我将非常高兴，这样我就可以开始解决这些问题。

我特别想知道的是:为什么系统决定重新启动？那天没有停电。我希望正常的重新引导会在日志中显示出来，是吗？

日志：

/var/logs/messages：https://pastebin.com/qgRumreB

/var/logs/syslog：https://pastebin.com/U5jpHNHm

日志已经完成了。我只是在开始和结束时删除了行，但没有在中间删除。

Answer 1

虽然我没有找到明确的解决办法，但我想与大家分享我所做的努力。希望这将为其他有类似问题的人提供灵感。

有一件事帮了我很大的忙(那时候还没有)，那就是切换到一个新的操作系统。我正在运行基于Ubuntu18.04的Armbian，日志现在不那么杂乱了。此外，一些次要的细节得到了改善。如果你降落在这里，并仍然运行阿姆斯延展，你应该升级。

频繁崩溃的一个原因可能是由频繁崩溃引起的损坏的文件系统 :-(。Armbian用

  UUID=<uid> / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1

注意commit=600，这意味着每10分钟只编写一次更改。如果您的计算机在中间崩溃，文件系统可能会损坏。因此，您可以在SD卡文件系统上运行fsck.ext4。为了解决这一问题，你可以：

• 在每次启动时运行fsck
• 省略提交设置。我的SD卡可以很好地处理额外的压力。

我认为解决了这个问题的是，把我的外部硬盘，通过SATA连接，以睡眠。我感到惊讶的是，这种情况不会自动发生。现在我将下面的部分附加到我的/etc/hdparm.conf中

/dev/disk/by-uuid/<uid> {
    spindown_time = 60
    write_cache = off
}

这告诉hdparm在不活动5分钟后将HDD置于待机状态。关闭写缓存是防止文件系统再次损坏的安全措施。有些磁盘在不应该写入指令的情况下重新排序BtrFS。

我观察到的是，对机器施加了一些负载，帮助保持了系统的活力。不幸的是，只有到某个时候才是这样。但是，如果附加键盘和鼠标，或者让脚本在整个过程中运行有助于重新启动，那么您将有一些工作要做。

我使用下面的脚本来记录可能对我有帮助的信息，以防崩溃：

#!/bin/bash

# LICENSE: GPLv3 or later

set -euo pipefail

LOGFILE=/home/mgoerner/error-detection.log


function main() {
    parse_cli_args "$@"
    while true
    do
        print_debug_information >>"$LOGFILE" 2>&1
        sync
        sleep 3m
    done
}


function parse_cli_args() {
    if [[ $# -eq 1 ]]
    then
        arg="$1";shift
        if [[ "$arg" == "--help" || "$arg" == "-h" ]]
        then
            print_usage
            exit
        fi
        LOGFILE="$arg"
    elif [[ $# -gt 1 ]]
    then
        echo "Please provide at most one argument!" >&2
        exit 1
    fi
}


function print_usage() {
    cat <<EOF
$0 [LOGFILE]
EOF
}

function print_debug_information() {
    echo
    date
    uptime
    dmesg -uT | tail
    ip addr show wlxd85d4c97e434
    iwlist wlxd85d4c97e434 scan | egrep ESSID
    hdparm -acdgkmurC /dev/sda
    free
}


main "$@"

我让它在启动后自动启动。将睡眠时间设置在~10分钟以下，用来让崩溃消失，但现在没有了。不幸的是，此脚本生成的错误日志无助于获得任何洞察。来自/var/log/的各种日志也是如此。不过，这对你来说可能不一样。

此外，我怀疑我的WiFi dongle不喜欢温暖的。我重新使用了一个孩子的鞋盒作为箱子，然后把软线放进封闭的盒子里，造成了一些连接问题。

最后但并非最不重要的一点是，我在重新启动之后关闭了自动更新。很多时候，崩溃是在一些(神秘的)重启之后直接发生的。经过自动更新之后，我完全摆脱了这种情况。