Вопросы Теги

Есть ли причина, по которой /var/log/lastlog является огромным разреженным файлом (1,1 ТБ )?

Я понял. Специальные случаи Bash -\e, \[и \]в PS1. Он преобразует \eв управляющий байт, \[в байт 1и \]в байт 2. Внешние команды должны записывать 1и 2байт на стандартный вывод.

Согласно ASCII, они кодируют «начало заголовка» и «начало текста».

http://www.columbia.edu/kermit/ascii.html

Вот рабочий пример, основанный на преобразовании printf \escape-символов в первом позиционном параметре в правильные байты:

PS1='$( render-prompt )'
function render-prompt {
  printf '\1\033[0;35m\2$ \1\033[00m\2'
}

render-prompt | hexdump -C

00000000  01 1b 5b 30 3b 33 35 6d  02 24 20 01 1b 5b 30 30  |..[0;35m.$..[00|
00000010  6d 02                                             |m.|
00000012

5
12.07.2019, 16:39
4 ответа

What I hence wonder is, what is the need/backgrounding motivation to have those files as sparse, huge files (in my case it was 1.1TB)?

Так и должно быть.

/var/log/lastlogне является файлом журнала, как /var/log/syslog, и его имя следует читать как «список последних входов в систему», а не как «последний файл журнала».

Поддерживается модулем pam_lastlog(8),и это в основном такой массив:

struct lastlog {
    time_t  ll_time;    // 4
    char    ll_line[UT_LINESIZE];   // 32
    char    ll_host[UT_HOSTSIZE];   // 256
} entry[UINT_MAX];

Размеры полей на типичной машине x86 -64 указаны в комментариях; запись должна быть 4 + 32 + 256 = 292 байта.

Каждый раз, когда программа, использующая модуль pam pam_lastlog(8), регистрирует пользователя, она будет искать uid * sizeof(struct lastlog)и перезаписывать запись, соответствующую этому пользователю.

did I corrupt anything with truncating those files ?

Вы испортили вывод команды lastlog(1), которую все равно никто не использует;-)

13
27.01.2020, 20:40

Путем "усечения файла" без информирования (или перезапуска )программ, записывающих в файл журнала, ВЫ создали разреженный файл.

Лучшее решение — найти и устранить проблему, вызывающую все эти сообщения в журнале.

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

В соответствии с запросом, вот модель того, как это (не работает ):

Программа открывает файл для «добавления», ей сообщают, что файл заканчивается в блоке X, и записывает блок X+1. Вы «обрезаете файл», но программа «знает», что следующий блок для записи — это X+2. Таким образом, файл может давать данные в начале, но точно иметь данные в блоке X+2. Та -Да! Разреженный файл.

-2
27.01.2020, 20:40

Эти 2 файла являются файлами типа "данные", если вы проверите с помощью команды ls -l или ls -lh, то увидите, что они занимают очень много места на диске, но на самом деле это не

«ls -s» — это фактическая команда для проверки фактического размера этих файлов. 

[root@LinuxServer ~]# file /var/log/lastlog /var/log/faillog
/var/log/lastlog: data
/var/log/faillog: data
[root@LinuxServer ~]# ls -l /var/log/lastlog /var/log/faillog
-rw------- 1 root osg       3166464 Jul  8 21:20 /var/log/faillog
-rw-r--r-- 1 root root 304854077980 Jul 14 21:38 /var/log/lastlog
[root@LinuxServer ~]# ls -lh /var/log/lastlog /var/log/faillog
-rw------- 1 root osg  3.1M Jul  8 21:20 /var/log/faillog
-rw-r--r-- 1 root root 284G Jul 14 21:38 /var/log/lastlog
[root@LinuxServer ~]#

Фактический размер составляет всего несколько КБ, если проверить с помощью команды «ls -s».

[root@LinuxServer ~]# ls -s /var/log/lastlog /var/log/faillog
3100 /var/log/faillog   748 /var/log/lastlog
[root@LinuxServer ~]# ls -s /var/log/faillog
3100 /var/log/faillog
[root@LinuxServer ~]#
-1
27.01.2020, 20:40

Я наблюдал такое поведение после того, как мы ввели некоторые (большие )номера UID LDAP, -существующие с «обычными» номерами UID UNIX на машине с Linux (RHEL 7 ).

Кроме того, в разделе «ПРЕДОСТЕРЕЖЕНИЯ» страницы руководства для «lastlog» указано, что 

  *"Large gaps in UID numbers will cause the lastlog program to run longer with no output to the screen"*

«lastlog» будет зависать при обработке записей с промежуточными неиспользуемыми UID

Возможно, это также может быть связано с наблюдаемой проблемой, поскольку назначенные номера UID LDAP FreeIPA были намного больше, чем те, что были в Linux

1
25.08.2020, 11:19

Теги

Похожие вопросы