Re: вопрос по .xsession-errors

[Oleksandr Gavenko]

On 2015-11-23, Melleus wrote:

> 1. имеем файл ~/.xsession-errors
>
> 2. в него кто-то раз в несколько секунд с завидным постоянством пишет
> следующее:
>
> sh: 1: iwconfig: not found
>
> Обнаружил случайно, решил заглянуть, почему такой большой размер у
> файла. А там - это.
>
> Вопрос - как разобраться, что происходит? 

  $ sudo apt-get install auditd

  $ sudo auditctl -w ~/.xsession-errors -p w

Ждать и затем анализировать /var/log/audit/audit.log, или:

  $ sudo ausearch -f ~/.xsession-errors

В конце:

  $ sudo auditctl -W ~/.xsession-errors
  $ sudo service auditd stop
  $ sudo update-rc.d auditd disable

Я попробовал:

  $ sudo auditctl -w /tmp -p w

При старте xterm в логе есть строчка:

  type=SYSCALL msg=audit(1448308853.684:34): arch=c03e syscall=87
  success=yes exit=0 a0=24218a0 a1=7ffe55d12880 a2=7ffe55d12880
  a3=7ffe55d12640 items=2 ppid=3522 pid=12342 auid=4294967295 uid=1000
  gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000
  tty=(none) ses=4294967295 comm="xterm" exe="/usr/bin/xterm" key=(null)

Тут у нас pid, ppid, uid, gid, а также:

  comm="xterm" exe="/usr/bin/xterm"

что очень удобно для быстро исчезающих скриптов.

> Извиняюсь за шум, методом исключения выяснил, что это awesome
> виноват.

Я полагаю таким способом Вы бы прямо получили ответ без "метода исключения".

Чесно говоря до Вашего поста я о auditctl ничего не знал, но недавно отлаживал
CLASSPATH в Tomcat и там оказалось классным:

  $ inotifywait -m -r /tmp

Но inotify не рассказывает какие pid задействованы. inotify можно узнать какие
файлы трогают, но этого не достаточно в Вашем случае.

Для себя поискал как решается задача, что б знать на будущее, auditd -
дополнительно говорит кто трогает.

Там еще есть какие то штуки:

  https://en.wikipedia.org/wiki/File_Alteration_Monitor

-- 
Best regards!

вопрос по .xsession-errors

[Melleus]

Прошу подсказки в такой ситуации:

1. имеем файл ~/.xsession-errors

2. в него кто-то раз в несколько секунд с завидным постоянством пишет
следующее:

sh: 1: iwconfig: not found

3. с сетью (и вообще с системой в целом) видимых проблем нет, все
работает.

Обнаружил случайно, решил заглянуть, почему такой большой размер у
файла. А там - это.

Вопрос - как разобраться, что происходит? 

Спасибо заранее.

ЗЫ. Комп используется как декстоп (писательство, я не настоящий
айтишник). Сижу на стабильной ветке, десктопом awesome заведует, сетью -
network manager.

Re: вопрос по .xsession-errors

[Melleus]

Извиняюсь за шум, методом исключения выяснил, что это awesome
виноват.

Re: вопрос по .xsession-errors

[Eugene Berdnikov]

On Mon, Nov 23, 2015 at 02:18:26PM +0200, Melleus wrote:
> Прошу подсказки в такой ситуации:
> 
> 1. имеем файл ~/.xsession-errors
> 
> 2. в него кто-то раз в несколько секунд с завидным постоянством пишет
> следующее:
> 
> sh: 1: iwconfig: not found
> 
> 3. с сетью (и вообще с системой в целом) видимых проблем нет, все
> работает.
> 
> Обнаружил случайно, решил заглянуть, почему такой большой размер у
> файла. А там - это.
> 
> Вопрос - как разобраться, что происходит? 

 Проще всего сделать исполняемый файлик iwconfig с командочкой вроде
 ps auxfww | mail -s iwconfig root
 Можете подставить свой e-mail по вкусу. Есть и другие решения.
-- 
 Eugene Berdnikov

Re: вопрос по .xsession-errors

[Melleus]

Eugene Berdnikov  writes:

> On Mon, Nov 23, 2015 at 02:18:26PM +0200, Melleus wrote:
>> Прошу подсказки в такой ситуации:
>> 
>> 1. имеем файл ~/.xsession-errors
>> 
>> 2. в него кто-то раз в несколько секунд с завидным постоянством пишет
>> следующее:
>> 
>> sh: 1: iwconfig: not found
>> 
>> 3. с сетью (и вообще с системой в целом) видимых проблем нет, все
>> работает.
>> 
>> Обнаружил случайно, решил заглянуть, почему такой большой размер у
>> файла. А там - это.
>> 
>> Вопрос - как разобраться, что происходит? 
>
>  Проще всего сделать исполняемый файлик iwconfig с командочкой вроде
>  ps auxfww | mail -s iwconfig root
>  Можете подставить свой e-mail по вкусу. Есть и другие решения.

Все гениальное - просто. И тот, кто дернет за ниточку, спалит себя сам
:) Спасибо за идею!

Re: вопрос по .xsession-errors

[Melleus]

Oleksandr Gavenko  writes:

> On 2015-11-23, Oleksandr Gavenko wrote:
>
> Это не поможет топикстартеру, но интересно было разобраться, а то смешно,
> когда то на работе в цикле грепали ps:
>
>   while true;
> ps -e | grep COND
> sleep 1
>   done

Спасибо. Это целая пушка для моего воробья. Сначала исключением угадал с
первого раза. А потом еще и закладку сделал. Закладка сработала и
указала на awesome. А анализ конфига привел к библиотеке obvious, автор
которой и дергал неосторожно iwconfig (пока поставил на него линк в
~/bin в качестве костыля). В общем-то изменения формата конфигурационных
файлов с каждой версией awesome как-бы намекают на некоторую сырость
продукта. И, вместе с этим, лучшей альтернативы пока не вижу. И не
очень-то хочу, чтобы в стабильную ветку приползло обновление. Когда все
уже настроено под себя...

Re: вопрос по .xsession-errors

[Oleksandr Gavenko]

On 2015-11-23, Oleksandr Gavenko wrote:

> Я попробовал:
>
>   $ sudo auditctl -w /tmp -p w
>
> При старте xterm в логе есть строчка:
>
>   type=SYSCALL msg=audit(1448308853.684:34): arch=c03e syscall=87
>   success=yes exit=0 a0=24218a0 a1=7ffe55d12880 a2=7ffe55d12880
>   a3=7ffe55d12640 items=2 ppid=3522 pid=12342 auid=4294967295 uid=1000
>   gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000
>   tty=(none) ses=4294967295 comm="xterm" exe="/usr/bin/xterm" key=(null)
>
> Тут у нас pid, ppid, uid, gid, а также:
>
>   comm="xterm" exe="/usr/bin/xterm"
>
> что очень удобно для быстро исчезающих скриптов.

Я боялся что не будет имени исполняемого файла.

Есть lastcomm из пакета acct (который также запускает сервис):

  bash# lastcomm 
  lastcomm   user pts/3  0.00 secs Mon Nov 23 22:38
  sh user pts/8  0.00 secs Mon Nov 23 22:37
  awkuser pts/8  0.00 secs Mon Nov 23 22:37
  seduser pts/8  0.00 secs Mon Nov 23 22:37
  manuser pts/8  0.01 secs Mon Nov 23 22:37

Согласно ACCT(5):

   If the kernel is built with the process accounting option enabled
   (CONFIG_BSD_PROCESS_ACCT), then calling acct(2) starts process
   accounting, for example:

   acct("/var/log/pacct");

/var/log/pacct - бинарный файл, lastcomm помагает его читать.

Мне очень жаль что нет полного пути к команде и нет опций запуска и нет PWD.
Эта информация очень бы помогла в отладке.

Можно попробовать стартовать пользователькую сесию с

  $ cat ~/.xinitrc
  ...
  strace -e execve -o ~/strace.log -f LASTCOMMAND

Будет вылазить:

  bash# strace -e execve -f sh -c "/bin/echo ok"
  execve("/bin/sh", ["sh", "-c", "/bin/echo ok"], [/* 59 vars */]) = 0
  Process 14651 attached
  [pid 14651] execve("/bin/echo", ["/bin/echo", "ok"], [/* 59 vars */]) = 0
  ok
  [pid 14651] +++ exited with 0 +++
  --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=14651, si_uid=1000, 
si_status=0, si_utime=0, si_stime=0} ---
  +++ exited with 0 +++

Там пытаться воспроизвести проблемную ситуацию.

Текущий каталог мониторить по:

  $ strace -e chdir,execve -f xterm

Далее нашел:

  $ sudo forkstat

  23:06:33 exec  15004 /bin/bash -c  exec xterm -e bash -i
  23:06:33 exec  15004 xterm -e bash -i
  23:06:33 fork  15004 parent  xterm -e bash -i
  23:06:33 fork  15005 child   xterm -e bash -i
  23:06:33 exec  15005 bash -i
  23:06:33 fork  15005 parent  bash -i
  23:06:33 fork  15006 child   bash -i
  23:06:33 fork  15006 parent  bash -i
  23:06:33 fork  15007 child   bash -i
  23:06:33 exec  15007 dircolors -b /home/user/.dircolors
  23:06:33 exit  15007  00.001 dircolors -b /home/user/.dircolors
  23:06:33 exit  15006  00.001 bash -i
  23:06:33 fork  15005 parent  bash -i
  23:06:33 fork  15008 child   bash -i
  23:06:33 fork  15008 parent  bash -i
  23:06:33 fork  15009 child   bash -i
  23:06:33 exec  15009 ls /etc/bash_completion.d
  23:06:33 exit  15009  00.002 ls /etc/bash_completion.d
  ...

Это не поможет топикстартеру, но интересно было разобраться, а то смешно,
когда то на работе в цикле грепали ps:

  while true;
ps -e | grep COND
sleep 1
  done

-- 
Best regards!