☰

/var/log/lastlog가 거대한 희소 파일(1.1TB)인 이유가 있나요?

tag-icon • tag-icon logs sparse-files
/var/log/lastlog가 거대한 희소 파일(1.1TB)인 이유가 있나요?

나는 파일을 효율적으로 희소화 하는 방법을 묻는 몇 가지 질문을 읽었고 rsync, 파일 /var/log/lastlog과 /var/log/faillog.

그래서 제가 궁금한 것은 이러한 파일을 드물게 큰 파일(내 경우에는 1.1TB)로 갖는 필요성/배경 동기가 무엇입니까?

이에 관련된 후속 조치: 로그 파일이라고 가정하고 있기 때문에 이 파일을 자르는 것에 별로 관심이 없습니다. 이 파일을 잘라서 손상시킨 것이 있습니까?

답변1

그래서 제가 궁금한 것은 이러한 파일을 드물게 큰 파일(내 경우에는 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)해당 사용자에 해당하는 항목을 찾아 덮어씁니다.

이 파일을 잘라서 손상된 부분이 있나요?

당신은 실제로 명령의 출력을 손상시키고 lastlog(1)있으며 어쨌든 아무도 그것을 사용하지 않을 것입니다 ;-)

답변2

Linux(RHEL 7) 시스템에서 "일반" UNIX UID 번호와 공존하기 위해 일부 (큰) LDAP UID 번호를 도입한 후에 이 동작을 확인했습니다.

또한 "lastlog" 매뉴얼 페이지의 "CAVEATS" 섹션에는 다음과 같이 나와 있습니다.

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

중간에 사용되지 않은 UID가 있는 항목을 처리할 때 "lastlog"가 중단된 것처럼 보입니다.

할당된 FreeIPA LDAP UID 번호가 Linux의 UID 번호보다 훨씬 크기 때문에 이는 관찰된 문제와도 관련이 있을 수 있습니다.

답변3

이 두 파일은 "데이터" 유형 파일입니다. using 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명령으로 확인하면(출력은 -s디스크 블록 단위임) 실제 크기는 몇 KB에 불과합니다.

[root@LinuxServer ~]# ls -s /var/log/lastlog /var/log/faillog
3100 /var/log/faillog   748 /var/log/lastlog

답변4

로그 파일에 쓰고 있는 프로그램에 알리거나 다시 시작하지 않고 "파일을 자르면" 스파스 파일이 생성됩니다.

가장 좋은 해결책은 이러한 모든 로그 메시지의 원인이 되는 문제를 찾아서 해결하는 것입니다.

문제를 방지하는 또 다른 방법은 로깅 서비스를 중지하고 lsof다른 프로세스에서 파일이 열려 있지 않은지 확인한 다음 파일을 자르고 로깅을 다시 시작하는 것입니다.

요청에 따라 작동 방식에 대한 모델은 다음과 같습니다.

프로그램은 "추가"를 위해 파일을 열고 파일이 블록 X에서 끝난다는 메시지를 듣고 블록 X+1을 씁니다. 사용자는 "파일을 자르지만" 프로그램은 쓸 다음 블록이 X+2라는 것을 "알고 있습니다". 따라서 파일이 처음에는 데이터를 제공할 수 있지만 X+2 블록에는 분명히 데이터가 있을 것입니다. 다다! 스파스 파일.

관련 정보