Отримання дати та часу запуску системи в Linux


44

Я знаю, що uptimeдрукує час запуску та роботи машини, але чи є простіший (надійний) спосіб отримати дату запуску, ніж відлік цього результату?

Я спробував озирнутися /proc, але нічого значного не знайшов. Також є такий рядок на моєму dmesg:

[    0.673492] rtc_cmos rtc_cmos: setting system clock to 2011-03-14 14:26:52 UTC (1300112812)

Але мені цікаво, чи цей метод є розповсюдженням та версією ядра?


Що unreliable or hardпро uptime?
Боббі

2
@Bobby: Нічого про команду чи її функції, але як сказано, я хочу отримати дату та час останнього завантаження системи, а не скільки часу минуло з тих пір. uptimeповертає рядок типу "до 13 днів, 21:01", і вам потрібно буде порахувати це.
jho

4
Нераціонально відраховуватися від значення безперервного часу. Якщо ти хочеш надійного , ти хочеш /proc/uptime.
sam hocevar

Відповіді:


40

Я знайшов тут кілька команд . Спробуйте who -bабо last reboot | head -1.
whoдає числові дати, а last rebootповертає скорочені імена день / місяць.


а як бути, якщо ми хочемо лише дати та нічого іншого?
T0xicCode

4
who -b | cut -d' ' -f13тільки дата повернення (-f14 повертається час)
charlesbridge

2
Попередження: last rebootне дав мені правильної дати! who -bзробила.
qwertzguy

last rebootдав мені також неправильну дату, wtmp, здавалося, був повернутий перший день місяця
golimar

23

Це запитує час роботи у ядрі та відображає його у локальному часовому поясі:

date -d "`cut -f1 -d. /proc/uptime` seconds ago"

Будьте уважні до інших варіантів. lastКоманда перестане працювати , як тільки wtmpбуло повернуто. whoКоманда залежить від наявності та цілісності utmp. І /proc/1може мати поточну дату замість дати завантаження і навіть може бути недоступною у загартованій системі. Редагувати : dmesgмає лише задній буфер фіксованої довжини, тому він також ненадійний. Журнали ядра можуть бути, /var/logале більшість дистрибутивів зберігають їх лише 8 тижнів.


1
Цікаво, що це не погоджується who -bчерез хвилину чи дві в моїй системі 210-денного часу. Схоже, who -bзвітує часова марка, хоча на цей підрахунок якимось чином впливає переміщення годин, навіть якщо вони періодично виправляються бігом ntpd.
Руслан

3
Переглянувши всі альтернативні відповіді, зупинився на: date -d "`cut -f1 -d. /proc/uptime` seconds ago" -u(який має час / дату в UTC)
david6

Феноменальна відповідь. Якщо ядро ​​не знає, ніхто не знає - це джерело правди для системи. Секунди полегшують обчислення часу (я натрапив на це, тому що хочу знати "Хто з моїх хостів не перезавантажувався протягом останньої доби [86 400 секунд]?")
Майк S

17

Я наткнувся на це питання, шукаючи способу отримати послідовний, розбірливий час завантаження , на відміну від часу після завантаження, який змінюється під час кожного дзвінка.

Схоже, uptime -sце зробить трюк у більшості систем Linux.


uptime -sВиходи, наприклад 2017-08-09 01:23:45. Це найкраще, будучи найпростішим. Ця команда входить в пакет "propps".
teika kazura

uptimeУ CentOS 6 ( procps version 3.2.8) , здається, не підтримує це, до жаль.
mwfearnley

uptime -sне завжди повертає постійні результати: superuser.com/q/1247713/71144
cweiske

1
Зауважте, що це завжди в локальний час , але він фактично не друкує часовий пояс / зміщення. Отже, якщо ви хочете програмно витягнути це з машин, це не ідеально, оскільки вам може знадобитися окремо визначити їх часовий пояс, залежно від вашої ситуації використання. Отже, я б запропонував кілька інших відповідей.
JJC

11

Я знайшов btimeрядок, /proc/statколи тріскався

cat /proc/stat | grep btime | awk '{ print $2 }'

і після швидкого пошуку я знайшов цю сторінку: / proc / stat пояснив , де викладено "Різні відомості про діяльність ядра, які доступні у /proc/statфайлі".

Рядок "btime" дає час, коли система завантажилася, в секундах з епохи Unix.


1
Написати набагато простішеawk '/btime/{print $2}' /proc/stat
Вільям Персел

@WilliamPursell найпростіше - це завжди те, що ти вже знаєш. Я не чарівник. : P
Oddstr13

Влучне зауваження. Однак ви безкорисливо використовували кота. Просто зніміть файл.
Майк Ш

@MikeS правильний - однак я все ще стоюсь біля свого оригінального командного ланцюга як чітке уявлення про те, де знаходиться інформація, навіть через 7 років після моєї відповіді.
Oddstr13

8
  • добре : uptime -s, who -bабо синтаксичний/proc/uptime
  • погано : ls -ld /proc/1і варіанти.

Не використовуйте для цієї мети ls -ld / proc / 1. Іноді оновляється після s2disk або s2ram.

У моєму випадку who -bсказав:

завантаження системи 2 травня 09:51

Поки ls -ld /proc/1:

dr-xr-xr-x 7 корінь кореня 0 3 травня 13:09 / proc / 1

ls -ldдля /procабо, /sysздається, зберігається після поновлення, але це залежить від реалізації, і може змінитися в майбутньому, тому не використовуйте такі методи. І якщо ваш системний годинник у локальний час, а не по UTC , вони негативно зміщуються.

(Я ще не маю честі коментувати відповіді, тому відкрив нову відповідь. Вибачте.)

EDIT: uptime -sвперше у цій відповіді було проведено микегрелінг


2

Найпростіший спосіб - подивитись, коли / sbin / init запустився (це завжди перший процес, який запускається після завантаження ядра):

# ls -ld /proc/1
dr-xr-xr-x 7 root root 0 2011-03-27 23:54 /proc/1

Тож я бачу, що моя машина зарядилася о 6 хвилині до півночі 27 березня 2011 року.

Якщо ви хочете використовувати його в сценарії, ви можете використовувати statкоманду замість цього:

# stat --printf='%Y' /proc/1
1301266491

У %YВизначає час , оскільки каталог останньої зміни (час створення процесу) в секундах з початку епохи (1/1/70) і є стандартним Відмітка часу Unix.


1
На жаль, це не працює: mtime для цих папок може змінюватися з інших причин (у мене тут система, що має 5-денний режим роботи, а mtime / / proc / 1 - 25 хвилин тому)
kdt

1
Це не є надійним , як пояснено у моїй відповіді
teika kazura

1

У Linux

ls -ld /proc

здається, дає мені те, що мені потрібно. Повідомлення вище дивним. /proc/uptimeне містить значення дати - його потрібно було б відняти від поточного часу. Можливо, він мав на увазі:

date -d @$(( $(date +%s) - $(cut -f1 -d. /proc/uptime) ))

uptime -sнадає значення дати
мікгрелінг

1

Під Башем, без труб і інших процесів; просто текст:

$ REPLY="$(</proc/uptime)"
$ REPLY="${REPLY%%.*}"
$ echo "$REPLY"
31207

(Просто використовуйте REPLYзмінну за замовчуванням, але ви можете вибрати все, що вам потрібно)


Звісно, ​​чому б ні? Якесь розумне використання змінної підрядності. Класно. +1. Дякую за ідею!
Майк Ш

1

Це здається надійним і надасть вам його у форматі UTC та ISO8601. (Видаліть останні два варіанти, щоб відключити відповідно):

date -d "`cut -f1 -d. /proc/uptime` seconds ago" -u -Iseconds

0
date -d @$(sed -n '/^btime /s///p' /proc/stat)

(ще один спосіб зробити це, що корисно за певних обставин)


0

Команда:

(echo ' Currently:' | tr "\n" ' ' ; date +"%Y-%m-%d %k:%M:%S" ; echo '  Up Since:' | tr '\n' ' ' ; uptime -s ; echo '  Duration:' | tr '\n' ' ' ; uptime -p)

Вихід:

 Currently: 2016-05-09  9:06:29
  Up Since: 2016-05-04 12:56:04
  Duration: up 4 days, 20 hours, 10 minutes

0

Чітка та лаконічна команда tuptime :

# tuptime -t
No.             Startup Date                                          Uptime            Shutdown Date   End                    Downtime

1     09:43:39 AM 08/08/2017      41 days, 0 hours, 51 minutes and 2 seconds   10:34:41 AM 09/18/2017    OK                  10 seconds
2     10:34:51 AM 09/18/2017                         1 minute and 16 seconds   10:36:07 AM 09/18/2017    OK                    1 second
3     10:36:08 AM 09/18/2017                       13 minutes and 20 seconds   10:49:28 AM 09/18/2017    OK                   3 seconds
4     10:49:31 AM 09/18/2017       45 days, 0 hours, 1 minute and 20 seconds   09:50:51 AM 11/02/2017    OK                   4 seconds
5     09:50:55 AM 11/02/2017                       27 minutes and 25 seconds   10:18:20 AM 11/02/2017    OK                   4 seconds
6     10:18:24 AM 11/02/2017                                       9 seconds   10:18:33 AM 11/02/2017    OK                   9 seconds
7     10:18:42 AM 11/02/2017      4 days, 5 hours, 41 minutes and 47 seconds   04:00:29 PM 11/06/2017    OK                  44 seconds
8     04:01:13 PM 11/06/2017    15 days, 17 hours, 33 minutes and 48 seconds   09:35:01 AM 11/22/2017   BAD   10 minutes and 40 seconds
9     09:45:41 AM 11/22/2017               8 hours, 9 minutes and 20 seconds   05:55:01 PM 11/22/2017   BAD     7 minutes and 8 seconds
10    06:02:09 PM 11/22/2017                1 hour, 7 minutes and 54 seconds   07:10:03 PM 11/22/2017   BAD   11 minutes and 30 seconds
11    07:21:33 PM 11/22/2017               1 hour, 58 minutes and 32 seconds   09:20:05 PM 11/22/2017    OK                   5 seconds
12    09:20:10 PM 11/22/2017                       14 minutes and 52 seconds   09:35:02 PM 11/22/2017   BAD    5 minutes and 52 seconds
13    09:40:54 PM 11/22/2017                         4 minutes and 6 seconds   09:45:00 PM 11/22/2017   BAD    4 minutes and 51 seconds
14    09:49:51 PM 11/22/2017             11 hours, 15 minutes and 10 seconds   09:05:01 AM 11/23/2017   BAD    7 minutes and 20 seconds
15    09:12:21 AM 11/23/2017      3 days, 2 hours, 17 minutes and 40 seconds   11:30:01 AM 11/26/2017   BAD   27 minutes and 44 seconds
16    11:57:45 AM 11/26/2017   109 days, 19 hours, 12 minutes and 37 seconds   07:10:22 AM 03/16/2018    OK                  17 seconds
17    07:10:39 AM 03/16/2018     25 days, 3 hours, 55 minutes and 59 seconds   12:06:38 PM 04/10/2018    OK                   3 seconds
18    12:06:41 PM 04/10/2018      8 days, 19 hours, 3 minutes and 20 seconds   07:10:01 AM 04/19/2018   BAD    3 minutes and 52 seconds
19    07:13:53 AM 04/19/2018     77 days, 9 hours, 44 minutes and 39 seconds
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.