Bug 850 - I can't edit /etc/sudoers file. I tried to take away root privileges from some users to no avail. This poses a security risk right now.
I can't edit /etc/sudoers file. I tried to take away root privileges from som...
Status: RESOLVED WORKSFORME
Product: Sudo
Classification: Unclassified
Component: Visudo
1.8.6
PC Linux
: low high
Assigned To: Todd C. Miller
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-08-31 01:03 MDT by Godlove Ndofor
Modified: 2018-08-31 08:04 MDT (History)
0 users

See Also:


Attachments
Using lsof to troubleshoot and fix a bug in /etc/visudoers (78.36 KB, image/jpeg)
2018-08-31 07:58 MDT, Godlove Ndofor
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Godlove Ndofor 2018-08-31 01:03:07 MDT
[root@server1 ndofor]# visudo
visudo: /etc/sudoers busy, try again later
[root@server1 ndofor]#
Comment 1 Godlove Ndofor 2018-08-31 01:05:15 MDT
I have cleaned up my cached file and restarted my server (was authorized to restart) still no solution.
Comment 2 Todd C. Miller 2018-08-31 07:04:42 MDT
That error means that visudo was unable to lock /etc/sudoers.  This is usually because another visudo process is running.

If you have verified that no other visudo is running, you can use lsof to see if another process has /etc/sudoers open by running "sudo lsof /etc/sudoers".

If that doesn't show anything then there is something else preventing visudo from getting the lock.  You can use strace to see the actual error.  For example: "sudo strace -o /tmp/visudo.trace visudo"
Toward the end of the trace file you should see lines like:

openat(AT_FDCWD, "/etc/sudoers", O_RDWR|O_CREAT, 0440) = 3
fcntl(3, F_SETLK, {l_type=F_WRLCK, l_whence=SEEK_CUR, l_start=0, l_len=0}) = -1 EAGAIN (Resource temporarily unavailable)

If the F_SETLK failure is something other than EAGAIN that might provide a clue as to why visudo is not working.
Comment 3 Godlove Ndofor 2018-08-31 07:58:33 MDT
Created attachment 514 [details]
Using lsof to troubleshoot and fix a bug in /etc/visudoers

Thanks for your support Todd.
All I needed to do was to figure out the PID and delete. That worked perfectly well as seen in image.