0

On Linux server there are many log messages like these:

Jul 17 09:22:34 sweden sudo[3631848]: pam_unix(sudo:auth): auth could not identify password for [myuser]
Jul 17 09:22:34 sweden sudo[3631848]: pam_sss(sudo:auth): authentication failure; logname= uid=30044 euid=0 tty= ruser=myuser rhost= user=myuser
Jul 17 09:22:34 sweden sudo[3631848]: pam_sss(sudo:auth): received for user myuser: 7 (Authentication failure)
Jul 17 09:22:35 sweden sudo[3631849]: pam_unix(sudo:auth): Couldn't open /etc/securetty: No such file or directory
Jul 17 09:22:35 sweden sudo[3631849]: pam_unix(sudo:auth): conversation failed

They are produced by an unknown program which just floods the journal. Every ~500ms a new process is spawned, but I cannot identify the origin (neither command, nor its parent).

How can I stop (SIGSTOP) such a process, which lives for extremely short time and always changes its PID?

I have tried to see it with watch -n0.1 'ps fuxww', but nothing appears there.

1
  • This was happening, because something left after failed Ansible task spawning an elusive process. I had have to reboot the machine and the problem went away.
    – Sergio
    Dec 7, 2021 at 11:58

1 Answer 1

0
  1. Look for processes running as myuser and investigate what they do.

  2. Run crontab -u myuser -l to see if they have any cron jobs that run sudo (either directly in the crontab entry or in a script run from cron)

  3. grep myuser /etc/crontab /etc/cron*/* in case there are any system cron jobs for myuser.

  4. run atq to see if they have any at jobs queued.

  5. Also look in ~myuser/.config/systemd/user/ to see if they have any systemd timer jobs scheduled.

  6. run grep -r pam_securetty /etc/pam.d/ to find out which pam services are configured to use securetty when you don't even have an /etc/securetty file(*). sudo will be one of them because that's what's generate the auth log messages, perhaps others, perhaps one of the /etc/pam.d/common-* files.

(*) /etc/securetty is used to limit which ttys root is allowed to login on.

2
  • Thanks for the answer, that is nice summary for searching scheduled tasks. I didn't find there any scheduled tasks though, because my problem was caused by interrupted or failed Ansible task, which was spawning a process on its own.
    – Sergio
    Dec 7, 2021 at 12:00
  • I would include systemctl list-timers and systemctl --user list-timers in this list as well. Systemd collects even user units from different "system" directories, like: /etc/systemd/user, /usr/local/lib/systemd/user etc. (see man 5 systemd.unit)
    – Sergio
    Dec 7, 2021 at 12:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .