Bug 12564

Не наблюдаю ничего подобного.
Попробуйте strace'ить приложения, от которых не доходят логи.

(In reply to comment #1)
> Не наблюдаю ничего подобного.
> Попробуйте strace'ить приложения, от которых не доходят логи.

попробую

попутный вопрос: почему мне перестали приходить письма от багзиллы?

Обязательно попробуйте.

Ответ на попутный вопрос: у домена altlinux.* сломался MX.

Created attachment 2146 [details]
Logger program

Created attachment 2147 [details]
strace for absent log messages

Created attachment 2148 [details]
strace for success logging

Попробовал, программа и результаты strace приложены. Кстати, сейчас первое
потерянное сообщение вообще не пришло.

Как только сообщения перестанут писаться снова, погляжу на /dev/log, сейчас он
выглядит так:

# ls -l /dev/log
srw-rw-rw- 1 root root 0 Aug 15 09:40 /dev/log

Какое ядро, если ovz то HN или VE?

ядра std и wks

это называется напугал :(

раньше для воспроизведения было достаточно нескольких часов после рестарта
сислога, теперь не могу воспроизвести ни на одной машине ...

Итак, воспроизводится, /dev/log выглядит так:

# ls -l /dev/log
srwxr-xr-x 1 root root 0 Aug 17 02:03 /dev/log

> # ls -l /dev/log
> srwxr-xr-x 1 root root 0 Aug 17 02:03 /dev/log
 
Вопрос теперь в том, кто может менять права таким образом? За руку поймать
можно? Да, по ночам с машины снимается бэкап, при этом делается service udevd
umount и service udevd start, но этот глюк проявляется независимо: может до
umount/start, а может и после umount/start не появится.

Надо найти процесс, который портит /dev/log.
Повесьте на ежеминутный крон что-нибудь такое:
[ -w /dev/log ] || ps afxuww

Сделал

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

Можно ещё service acct start сделать.

Хм... Я что-то сделал не так?

[root@pbx ~]# service acct start
Turning on process accounting:                                                 
                                                       [ DONE ]
[root@pbx ~]# mcedit /var/account/pacct 

[root@pbx ~]# last-acct 
alexsis  pts/1        192.168.0.149    Fri Aug 17 14:35 - 14:35  (00:00)
alexsis  pts/1        192.168.0.149    Fri Aug 17 14:27 - 14:32  (00:04)
*** buffer overflow detected ***: last-acct terminated
======= Backtrace: =========
/lib64/libc.so.6(__chk_fail+0x2f)[0x2aec798214ff]
/lib64/libc.so.6[0x2aec79820ab9]
/lib64/libc.so.6(_IO_default_xsputn+0x8e)[0x2aec797bd69e]
/lib64/libc.so.6(_IO_vfprintf+0x14d2)[0x2aec79796802]
/lib64/libc.so.6(__vsprintf_chk+0x9d)[0x2aec79820b5d]
/lib64/libc.so.6(__sprintf_chk+0x80)[0x2aec79820aa0]
last-acct[0x4012ba]
last-acct[0x4016a9]
last-acct[0x401975]
last-acct[0x4020f6]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x2aec79772c14]
last-acct[0x400e29]
======= Memory map: ========
00400000-00405000 r-xp 00000000 09:00 197033                            
/usr/bin/last-acct
00604000-00605000 rw-p 00004000 09:00 197033                            
/usr/bin/last-acct
00605000-00626000 rw-p 00605000 00:00 0                                  [heap]
2aec7953c000-2aec79554000 r-xp 00000000 09:00 144329                    
/lib64/ld-2.5.so
2aec79554000-2aec79557000 rw-p 2aec79554000 00:00 0 
2aec79559000-2aec7955a000 rw-p 2aec79559000 00:00 0 
2aec79753000-2aec79754000 r--p 00017000 09:00 144329                    
/lib64/ld-2.5.so
2aec79754000-2aec79755000 rw-p 00018000 09:00 144329                    
/lib64/ld-2.5.so
2aec79755000-2aec79884000 r-xp 00000000 09:00 144335                    
/lib64/libc-2.5.so
2aec79884000-2aec79a83000 ---p 0012f000 09:00 144335                    
/lib64/libc-2.5.so
2aec79a83000-2aec79a86000 r--p 0012e000 09:00 144335                    
/lib64/libc-2.5.so
2aec79a86000-2aec79a88000 rw-p 00131000 09:00 144335                    
/lib64/libc-2.5.so
2aec79a88000-2aec79a8e000 rw-p 2aec79a88000 00:00 0 
2aec79a8e000-2aec79a9b000 r-xp 00000000 09:00 144386                    
/lib64/libgcc_s.so.1
2aec79a9b000-2aec79c9b000 ---p 0000d000 09:00 144386                    
/lib64/libgcc_s.so.1
2aec79c9b000-2aec79c9c000 rw-p 0000d000 09:00 144386                    
/lib64/libgcc_s.so.1
7fff31559000-7fff3156e000 rw-p 7fff31559000 00:00 0                      [stack]
ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0                  [vdso]
john     pts/3        10.0.0.1.don Fri Aug 17 11:17 Aborted

last-acct, похоже, не работает, но это совсем другая история.
Вам нужен lastcomm.

Вообще-то проблема с правами четко воспроизводится так:

# ls -l /dev/log
srw-rw-rw- 1 root root 0 Aug 20 08:48 /dev/log

# service udevd umount
Stopping udevd service:                                                        
                                                       [ DONE ]
Removing udev device nodes:                                                    
                                                       [ DONE ]

# ls -l /dev/log
ls: /dev/log: No such file or directory

# service udevd start
Starting udevd service:                                                        
                                                       [ DONE ]
Populating /dev:                                                               
                                                       [ DONE ]

# ls -l /dev/log
srwxr-xr-x 1 root root 0 Aug 20 08:48 /dev/log

# service syslogd restart
Stopping system logger service:                                                
                                                       [ DONE ]
Starting system logger service:                                                
                                                       [ DONE ]

# ls -l /dev/log
srw-rw-rw- 1 root root 0 Aug 20 08:49 /dev/log

И раньше я это прозевал наверное потому, что приложения, уже открывшие /dev/log,
продолжали работать и слать сообщения.

Такое поведение udevd нормально или вешать баг?

Непонятно, почему udevd после этой процедуры вообще создаёт /dev/log, тем более
с такими правами доступа.

Такая процедура - следствие лени (лень отдельно держать бэкап /dev/ и при
необходимости накатывать 2 бэкапа, хотя, конечно, и это обходится, если бэкапить
не сразу в архив, а использовать rsync). Есть смысл расследовать это поведение
или забить?

Портить права в данном случае может minilogd, запускаемый из initlog (пакет
service) при отсутствии /dev/log; в коде minilogd не видно вызовов umask() или
chmod().

Для бэкапа лучше использовать mount --bind / /куда/нибудь - вызов service udevd
umount при работающей системе чреват разнообразными неприятностями.

Так что, перевешиваем на `rpm -qf /sbin/minilogd` (service) или NOTABUG?

(В ответ на комментарий №23)
> Так что, перевешиваем на `rpm -qf /sbin/minilogd` (service) или NOTABUG?

перевесил

однако я давно поборол лень и сделал архив /dev при выключенном udev и теперь больше его никогда не трогаю

(In reply to comment #22)
> Портить права в данном случае может minilogd, запускаемый из initlog (пакет
> service) при отсутствии /dev/log; в коде minilogd не видно вызовов umask() или
> chmod().

OK, давайте рискнем сделать в minilogd права на /dev/log 0666.

service-0.5.22-alt1 -> sisyphus:

* Thu Jan 26 2012 Dmitry V. Levin <ldv@altlinux> 0.5.22-alt1
- start-stop-daemon: implemented support of /proc/%d/exe pointing
  to names with " (deleted)" prefix.
- minilogd: changed to create /dev/log socket world writable
  (closes: #12564).
- init.d/functions (UnmountFilesystems): implemented mountpoints
  decoding to match getmntent(3) behaviour (closes: #17118).
- init.d/functions (start_daemon):
  + added --background option (closes: #26529);
  + added --check option.
- service.8: imported from Fedora (closes: #22166).