Как вывести список значений последних uptime'ов?

Можно использовать awk, paste или while read для вычисления разницы между соседними значениями. Например:

Вариант с awk

last -x --time-format iso reboot | awk '
{ if (prev != "") print prev - $5; prev = $5 }'

Здесь prev хранит предыдущее время, и awk считает разницу.

Вариант с paste и awk

last -x --time-format iso reboot | awk '{print $5}' | paste -d ' ' - - | awk '{print $1, $2, $1 - $2}'

Этот вариант соединяет строки попарно (paste - -), после чего awk считает разницу.

Вариант с while read

prev=""
while read -r time; do
    if [ -n "$prev" ]; then
        echo "$(date -d "$prev" +%s) - $(date -d "$time" +%s)" | bc
    fi
    prev="$time"
done < <(last -x --time-format iso reboot | awk '{print $5}')

Этот скрипт переводит даты в секунды (date -d … +%s) и считает разницу с помощью bc.

Какой вариант тебе удобнее?

(С) ChatGPT

Спасибо, ни один из них не рабочий, но направление мысли понял.

(С) ChatGPT

направление мысли понял.

Мысли против течения:

#!/usr/bin/env bash

difftime_reversed() {
    read -r prev
    while read -r cur; do
        cur_ts=$(date -d "$cur" +%s)
        prev_ts=$(date -d "$prev" +%s)
        diff_sec=$((prev_ts-cur_ts))
        diff_days=$((diff_sec/60/60/24))
        diff_hours=$(((diff_sec/60/60)%24))
        diff_minutes=$(((diff_sec/60)%60))
        diff_seconds=$((diff_sec%60))
        echo "$cur" "$prev" $diff_sec "(${diff_days}d ${diff_hours}h ${diff_minutes}' ${diff_seconds}'')"
        prev=$cur
    done
}

uptimes_reversed() {
    last -x --time-format iso reboot | awk '{print $5}'
}

uptimes_reversed | difftime_reversed

Максимально похожая на вариант через SQL для примера из темы конструкция получилась такая:

last -x --time-format iso reboot | head -n 6 | awk '{if(!p) {"date -Is" | getline p}; print $5 " " p ; p=$5}' | xargs -L1 datediff -f '%d days, %H hours,  %M minutes,  %S seconds'

Ваш вариант, без dateutils, тоже рабочий. Спасибо.

(С) ChatGPT
ни один из них не рабочий

Кто-то ожидал обратное?

Я - нет, не ожидал. Но оно действительно иногда подсказывает куда думать. Уже делал так. Дословно с первого раза не умеет. Но ход мысли подсказывает точно.

Тут больше не ожидал, что ЛОРовцу придёт в голову туда пойти и скопировать сюда его ответ.

с нюансами

В т.ч. - внезапно в Ubuntu 22 datediff называется dateutils.ddiff.

Пакет dateutils и в ArchLinux, и в Ubuntu называется одинаково.

В своем варианте тоже хотел использовать datediff, а это минус 4 строки кода, но подумал, что вряд ли на сервере установены лишние ненужные утилиты.

Тогда уж заодно и вопрос для Админов.

0 days, 4 hours,  18 minutes,  48 seconds
0 days, 4 hours,  18 minutes,  19 seconds
2 days, 3 hours,  46 minutes,  30 seconds
0 days, 4 hours,  18 minutes,  48 seconds
0 days, 4 hours,  18 minutes,  10 seconds
0 days, 4 hours,  18 minutes,  54 seconds
0 days, 4 hours,  18 minutes,  46 seconds

Какие есть варианты? Что такого в Линуксах (или в железе) может происходить примерно 258 минут после запуска?

Сейчас-то ему планки памяти поменяли. Пока всё ровно. Но что за загадочные 258 минут были?

------

Это виртуалка внутри дедика. Сам дедик схлопывался без каких-либо видимых причин (со слов админов). Забирая с собой все виртуалки. Память на дедике поменяли. А горит, потому что у меня в этой виртуалке БД, которой крайне неполезны такие выключения/включения внезапные.

awk односточник

last -x --time-format iso reboot | head | awk 'BEGIN {getline;"date -d " $5 " +%s" | getline prev} function fmt(ts){d=int(ts/60/60/24);h=int(ts/60/60)%24;m=int(ts/60)%60;s=ts%60;print d"d",h"h",m"m",s"s"} { "date -d " $5 " +%s" | getline cur; fmt(prev-cur); prev=cur}'

Спасибо, и это сохраню на всякий )

Тогда так то место выглядит (если head убрать - он там для отладки нужен был только):

0d 4h 18m 48s
0d 4h 18m 19s
2d 3h 46m 30s
0d 4h 18m 48s
0d 4h 18m 10s
0d 4h 18m 54s
0d 4h 18m 46s

в районе 258 минут uptime и reboot.

Без логов - гадание на кофейной гуще.

Админы дедика уверяют, что ничего в логах нет. Просто вот как «электричество кончилось». Может электричество кончаться ровными отрезками?

Ну, если ИБП хочет потестировать батареи, а они дохлые совсем... Но, не знаю, какой ИБП хочет тест батарей через 258мин после включения. А с учётом:

Память на дедике поменяли

намекает, что память без ECC, так как иначе должны были быть логи ECC-ошибок. Возможно, никакого ИБП и нет.

Это недостаточно страшно, нужно gawk и использовать co-process. На awk вырезать даты и передавать в co-process date -f- '+%s', чтобы на каждую обрабатываемую дату не было запуска нового процесса...

память без ECC

точно ECC.

какая была выяснить не удалось.
сейчас поставили

	Manufacturer: Samsung
	Serial Number: 03CFFD8B
	Part Number: M393A4K40DB2-CVF

есть ещё такое:

mc0: 0 Uncorrected Errors with no DIMM info
mc0: 0 Corrected Errors with no DIMM info
mc1: 0 Uncorrected Errors with no DIMM info
mc1: 0 Corrected Errors with no DIMM info

Но в любом случае, даже если действительно память - почему ровные отрезки?

ИБП хочет потестировать батареи

Это крайне маловероятно. Подозреваю, что в ДЦ Хетцнера это немного не так работает, как в кладовке.

Как раз ИБП в кладовке обычно и не тестирует батареии, и не хочет и не умеет. Но, не думают, что на этом форуме есть кто-то из Хетцнера, который опишет, как там устроена система электропитания и сколько БП у сервера и т.д. Хотели вангование, получите.

Про память, это я к тому, что странно менять ECC память из-за ребутов, если ошибок по ECC нет.

258 мин — это может быть каждые 4 часа плюс 18 мин таймауты. Какая-нибудь система мониторинга извне что-то запрашивала у сервера по iLO (IPMI), а тот крошился.

На awk вырезать даты и передавать в co-process date -f- ‘+%s’

Это не про возможности awk, а про возможности date.

А вот если написать парсер iso date на awk, то это действительно страшно

а такое:

[Hardware Error]: Machine check events logged

и оно мне рисует временные интервалы между reboot

А зачем вам этот timestamp? Я посмотрел, у меня максимум 7 дней, это либо обновления с рекомендацией перезагрузить, либо я сам по какой-то причине перезагружал.

[Hardware Error]: Machine check events logged

Да уж. А мы тут однострочники сочиняем.

А зачем вам этот timestamp?

Ну вот - выяснилась какая-то худо/бедно закономерность. Всё лучше чем совсем ничего и барабашка.

у меня максимум 7 дней

На десктопах-то это обычное дело. У меня в локальном ArchLinux тоже примерно так. Сервера должны жить месяцами. А лучше - годами.

В, принципе, да, может. Я не спец в гадании по MCE, но, по идее, нужно ещё смотреть само сообщение, да на время появления. Бывает, что кривой bios приводит к подобному состоянию ещё при инициализации железа, сообщение выскакивает ещё в самом начале dmesg (меньше секунды от старта) и так всё и живёт.

А в целом, ИМХО, подобное сообщение повод не просто поменять память или проц или настройки в BIOS (таминги/напряжения, если там что-то накручено), но и к длительным стресс-тестам.

повод не просто поменять память

Вот-вот... Это и смущает. Не складывается картинка в «просто поменяем память» в мои представления, как это работает.. С другой стороны 14 суток uptime уже на новой памяти.

длительным стресс-тестам

Хетцнеры этот дедик уже забирали на 6 часов на тесты. Сказали ничего не нашли. Рядом с ним ещё стоят несколько дедиков у них - там по 300 дней uptime и всё чудесно.

Ладно. Спасибо. Попробую рассказать эту загадку «258 минут» нашим админам, чтоб те попытали ей уже админов Хетцнера. Должно же быть какое-то разумное объяснение этим ровным отрезкам.

pacman -S uptimed
systemctl enable --now uptimed

а потом

uprecords -B

всё уже придумано

Да, спасибо, это тоже видел.

Но прям совсем целый сервис для такой задачи - как-то перебор. Тем более, что данные-то точно есть. Надо только нарисовать.

этот сервис на С написан, ресурсов почти не потребляет (в отличие от питонщины всякой). просто поставил и забыл, даже настраивать не нужно. а когда нужно посмотреть статистику:

$ uprecords
     #               Uptime | System                                     Boot up
----------------------------+---------------------------------------------------
->   1   2041 days, 04:01:5 | Linux x.x.x           Wed Jul  3 20:04:54 2019
     2    87 days, 19:08:36 | Linux x.x.x           Mon Mar  4 17:40:08 2019
     3    32 days, 21:42:18 | Linux x.x.x           Fri May 31 17:27:06 2019
     4     0 days, 01:34:02 | Linux x.x.x           Wed Jul  3 18:30:26 2019
     5     0 days, 00:13:57 | Linux x.x.x           Wed Jul  3 17:51:50 2019
     6     0 days, 00:10:33 | Linux x.x.x           Wed Jul  3 16:22:17 2019
     7     0 days, 00:04:06 | Linux x.x.x           Wed Jul  3 16:14:44 2019
     8     0 days, 00:02:46 | Linux x.x.x           Wed Jul  3 17:48:38 2019
     9     0 days, 00:01:52 | Linux x.x.x           Wed Jul  3 16:35:06 2019
    10     0 days, 00:01:16 | Linux x.x.x           Wed Jul  3 16:03:55 2019
----------------------------+---------------------------------------------------
NewRec   1953 days, 08:53:2 | since                     Sun Sep 29 15:13:29 2019
    up   2161 days, 23:01:2 | since                     Mon Mar  4 17:40:08 2019
  down     0 days, 06:25:20 | since                     Mon Mar  4 17:40:08 2019
   %up               99.988 | since                     Mon Mar  4 17:40:08 2019

этот сервис на С написан, ресурсов почти не потребляет

Это сервис периодически (по умолчанию - минута) дергает систему (сисколы): получает время, читает, пишет файлы. Периодичность влияет на точность. Потребление CPU не сильно от языка зависит.