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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.