visudo no longer runs - visudo: /etc/sudoers.tmp unchanged [SOLVED]

graysky · 2010-09-06 22:36:54

It's vi! I can't run it as root or any other user for that matter... wtf?

$ vi
$
$ /usr/bin/vi
$

karol · 2010-09-06 22:39:04

graysky wrote:

It's vi! I can't run it as root or any other user for that matter... wtf?
$ vi
$
$ /usr/bin/vi
$

No error message :-(
Tried reinstalling vi?

anonymous_user · 2010-09-06 22:39:17

Reinstall it?

graysky · 2010-09-07 00:30:46

anonymous_user wrote:

Reinstall it?

I did several times.... same behavior

cesura · 2010-09-07 00:40:30

karol wrote:

itsbrad212 wrote:
What if you simply delete the file? Does it keep occuring?
Which file? /etc/sudoers.tmp? It's created when you type 'visudo' and removed when you exit it.

Isn't there a "nobackup" option or something that you can put into your vimrc? Or is that only for swap files?
*.tmp files are created when you edit a file and replaces the original file if you save it, or deleted if you don't, correct?

@graysky
Does this happen if you use:

vim /etc/sudoers

(I'm assuming it doesn't)

You could always use an alias :

alias visudo="/usr/bin/vim /etc/sudoers"

Last edited by cesura (2010-09-07 04:14:32)

skanky · 2010-09-07 15:57:11

Can you run ex?
Have you checked the version with what's in the repos (jin case your mirror is out of date)?

yejun · 2010-09-07 15:58:41

can you delete /etc/sudoers ?

cesura · 2010-09-07 20:19:16

yejun wrote:

can you delete /etc/sudoers ?

Similar to what I said:
https://bbs.archlinux.org/viewtopic.php … 57#p822257

To ellaborate:
You could always try backing up the contents of /etc/sudoers, deleting it, and then create a new file with the same permissions where you can place the contents of the former.

Last edited by cesura (2010-09-07 20:19:59)

whaler · 2010-09-08 06:05:17

I get the same, but with more verbose error output:

 # visudo
kate(11484): Session bus not found 

KCrash: Application 'kate' crashing...
KCrash: Attempting to start /usr/lib/kde4/libexec/drkonqi from kdeinit
sock_file=/root/.kde4/socket-Strev/kdeinit4__0
Warning: connect() failed: : Ingen slik fil eller filkatalog
KCrash: Attempting to start /usr/lib/kde4/libexec/drkonqi directly
drkonqi(11485): Session bus not found 

visudo: /etc/sudoers.tmp unchanged

Don't know where/how Kate gets into the picture. Visudo worked fine the last time (not too long ago) I needed to edit sudoers.

vi works o.k.
/usr/bin/vi works o.k. (of course)

This is funny.

Edit: BTW, I do have

 export EDITOR="kate"

in .bashrc, mainly for use with AUR, but I have had that setting literally for years...

Would it be safe (enough) to try editing sudoers with nano?

Last edited by whaler (2010-09-08 06:11:31)

skanky · 2010-09-08 08:45:47

You can do, check and see if your sudoers file gets visudo to check the $EDITOR value. If so, then you can change it.
If you do edit it manually, I would recommend running

visudo -c

to check the syntax. You can log in as root to resolve any issues.

whaler · 2010-09-08 14:01:20

Thank you. I used nano, and 'visudo -c' says "parsed OK".

'echo $EDITOR' returns "kate",
whereas 'echo $VISUAL' returns blank/nothing.

I guess visudo/sudoers are checking the $EDITOR value, but won't accept Kate. I would like Kate to remain the default KDE editor, but don't know how to set visudo (alone) to invoke vi. I find this very strange, as I believe visudo should go straight for vi without checking the $EDITOR value?

All the above was done as root.

Last edited by whaler (2010-09-08 14:06:34)

skunktrader · 2010-09-08 14:09:59

To override the value of EDITOR just for visudo, create a shortcut/alias containing this

EDITOR=vi visudo

Last edited by skunktrader (2010-09-08 14:10:15)

skanky · 2010-09-08 15:02:57

whaler wrote:

Thank you. I used nano, and 'visudo -c' says "parsed OK".
'echo $EDITOR' returns "kate",
whereas 'echo $VISUAL' returns blank/nothing.
I guess visudo/sudoers are checking the $EDITOR value, but won't accept Kate. I would like Kate to remain the default KDE editor, but don't know how to set visudo (alone) to invoke vi. I find this very strange, as I believe visudo should go straight for vi without checking the $EDITOR value?
All the above was done as root.

See man visudo. It should ignore $EDITOR by default unless specified in the sudoers file.

Normally, visudo does not honor the VISUAL or EDITOR environment variables unless they contain an editor in the aforementioned editors list. However, if visudo is configured with the --with-env-editor option or the env_editor Default variable is set in sudoers, visudo will use any the editor defines by VISUAL or EDITOR. Note that this can be a security hole since it allows the user to execute any program they wish simply by setting VISUAL or EDITOR.

You can also specify the editor use there:

eg:

Defaults editor=/usr/bin/nano

whaler · 2010-09-09 06:00:45

Thanks, skunktrader and skanky.

Skanky wrote:

See man visudo. It should ignore $EDITOR by default unless specified in the sudoers file.

Precisely. Something is amiss...

skanky · 2010-09-09 08:55:33

It will use $EDITOR if the editor specified there is in the list of allowed editors as set at compile time. Do you have a non-standard version?
I haven't worked out how to see which ones have been compiled in - I'm assuming it's just vi in the standard arch package?

graysky · 2010-09-10 00:08:39

Guys - the problem doesn't seem to be with my /etc/sudoers at all, the problem is with vi itself. I simply cannot run vi on my system as root or a normal user. I've tried removing and reinstall it, but I get the same behavior. Thoughts?

skanky · 2010-09-10 09:21:58

graysky wrote:

Guys - the problem doesn't seem to be with my /etc/sudoers at all, the problem is with vi itself. I simply cannot run vi on my system as root or a normal user. I've tried removing and reinstall it, but I get the same behavior. Thoughts?

What version is installed (eg do you have an out of date mirror and an old version)?
Can you run ex?
What is your vi ls -listing?

Can you find any error messages in a logfile when you try and run it?
What about using strace with vi?

If all else fails, do you have to use vi, could you set visudo to use vim instead?

graysky · 2010-09-10 20:02:24

-I tried the current and previous package of vi - both have the same effect.
-I cannot run ex - same effect as vi
-I looked for log files that vi would write to but found nothing

$ strace vi
execve("/usr/bin/vi", ["vi"], [/* 51 vars */]) = 0
brk(0)                                  = 0x221f000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f1fcee3e000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=123896, ...}) = 0
mmap(NULL, 123896, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f1fcee1f000
close(3)                                = 0
open("/lib/libncursesw.so.5", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0B\1\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=394095, ...}) = 0
mmap(NULL, 2456904, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f1fce9c9000
mprotect(0x7f1fcea1d000, 2093056, PROT_NONE) = 0
mmap(0x7f1fcec1c000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x53000) = 0x7f1fcec1c000
close(3)                                = 0
open("/lib/libc.so.6", O_RDONLY)        = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`\355\1\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1412384, ...}) = 0
mmap(NULL, 3521384, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f1fce66d000
mprotect(0x7f1fce7c0000, 2093056, PROT_NONE) = 0
mmap(0x7f1fce9bf000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x152000) = 0x7f1fce9bf000
mmap(0x7f1fce9c4000, 19304, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f1fce9c4000
close(3)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f1fcee1e000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f1fcee1d000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f1fcee1c000
arch_prctl(ARCH_SET_FS, 0x7f1fcee1d700) = 0
mprotect(0x7f1fce9bf000, 16384, PROT_READ) = 0
mprotect(0x7f1fcee3f000, 4096, PROT_READ) = 0
munmap(0x7f1fcee1f000, 123896)          = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
getpid()                                = 4773
rt_sigaction(SIGHUP, {SIG_IGN, [], SA_RESTORER|SA_RESTART, 0x7f1fce69f5e0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGHUP, {0x410190, [], SA_RESTORER|SA_RESTART, 0x7f1fce69f5e0}, {SIG_IGN, [], SA_RESTORER|SA_RESTART, 0x7f1fce69f5e0}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN, [], SA_RESTORER|SA_RESTART, 0x7f1fce69f5e0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGXFSZ, {SIG_IGN, [], SA_RESTORER|SA_RESTART, 0x7f1fce69f5e0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGINT, {SIG_IGN, [], SA_RESTORER|SA_RESTART, 0x7f1fce69f5e0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGTERM, {SIG_IGN, [], SA_RESTORER|SA_RESTART, 0x7f1fce69f5e0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGTERM, {0x410190, [], SA_RESTORER|SA_RESTART, 0x7f1fce69f5e0}, {SIG_IGN, [], SA_RESTORER|SA_RESTART, 0x7f1fce69f5e0}, 8) = 0
mmap(NULL, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f1fcee36000
open("/usr/lib/locale/locale-archive", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=1779408, ...}) = 0
mmap(NULL, 1779408, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f1fcec69000
close(3)                                = 0
brk(0)                                  = 0x221f000
rt_sigaction(SIGTSTP, {SIG_IGN, [], SA_RESTORER|SA_RESTART, 0x7f1fce69f5e0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGTSTP, {0x40fca0, [], SA_RESTORER|SA_RESTART, 0x7f1fce69f5e0}, {SIG_IGN, [], SA_RESTORER|SA_RESTART, 0x7f1fce69f5e0}, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigaction(SIGINT, {0x410140, [], SA_RESTORER|SA_RESTART, 0x7f1fce69f5e0}, {SIG_IGN, [], SA_RESTORER|SA_RESTART, 0x7f1fce69f5e0}, 8) = 0
rt_sigaction(SIGTSTP, {0x40fca0, [], SA_RESTORER|SA_RESTART, 0x7f1fce69f5e0}, {0x40fca0, [], SA_RESTORER|SA_RESTART, 0x7f1fce69f5e0}, 8) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
stat("/home/user/.terminfo", 0x7fffe108acb0) = -1 ENOENT (No such file or directory)
stat("/usr/share/terminfo", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
access("/usr/share/terminfo/x/xterm", R_OK) = 0
open("/usr/share/terminfo/x/xterm", O_RDONLY) = 3
read(3, "\32\0010\0&\0\17\0\235\1l\5xterm|xterm terminal"..., 4097) = 3258
close(3)                                = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, TIOCGWINSZ, {ws_row=25, ws_col=105, ws_xpixel=0, ws_ypixel=0}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(0, TIOCGWINSZ, {ws_row=25, ws_col=105, ws_xpixel=0, ws_ypixel=0}) = 0
getsid(0)                               = 4491
getpgid(0)                              = 4772
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
stat("/home/user/.exrc", 0x7fffe108c5e0) = -1 ENOENT (No such file or directory)
getcwd("/home/user", 8192)           = 14
stat("/var/tmp", 0x7fffe108c5b0)        = -1 ENOENT (No such file or directory)
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
write(1, "\33[?1049h\33[25;1H\"/var/tmp\" ", 26)               = 8
exit_group(1)                           = ?

skanky · 2010-09-10 20:17:50

vi uses /var/tmp to store files in while editing them. It says you don't have one.
If you don't you could try and create one - or look into why it thinks you don't.

Or you can create a .exrc file and add a directory option to point elsewhere, or set the EXINIT environment variable to contain the command to point elsewhere, instead.
See the ex manual. I *think* it's

se directory=NEWDIR

in both.

Last edited by skanky (2010-09-10 20:19:46)

graysky · 2010-09-10 20:56:26

Thanks! I have my /tmp in tmpfs. Here is my /etc/fstab for it... perhaps I f*cked it up?

none    /tmp    tmpfs    nodev,nosuid,nodiratime,noatime,size=2000M,mode=1777    0    0

skanky · 2010-09-10 21:14:57

This is /var/tmp, not /tmp.

Though I don't really know enough about stuff to say that that's definitely the issue. It just is the last thing before it shuts down.

graysky · 2010-09-11 00:23:00

I misread your post. Indeed, /var/tmp was gone. I just added it and now all is well! I'll mark this as solved. It only took 45 replies! Thanks very much for the suggestion to use strace (never heard of it before).

Last edited by graysky (2010-09-11 00:28:03)

skanky · 2010-09-11 19:35:37

Nice one. It's always good to get the bottom of these sorts of issues.

R00KIE · 2010-09-11 21:33:02

Thats good to know you have found a solution
If you find what caused /var/tmp to vanish do let us know at least I am interested in knowing that, it might be needed in the future.

Arch Linux

#26 2010-09-06 22:36:54

Re: visudo no longer runs - visudo: /etc/sudoers.tmp unchanged [SOLVED]

#27 2010-09-06 22:39:04

Re: visudo no longer runs - visudo: /etc/sudoers.tmp unchanged [SOLVED]

#28 2010-09-06 22:39:17

Re: visudo no longer runs - visudo: /etc/sudoers.tmp unchanged [SOLVED]

#29 2010-09-07 00:30:46

Re: visudo no longer runs - visudo: /etc/sudoers.tmp unchanged [SOLVED]

#30 2010-09-07 00:40:30

Re: visudo no longer runs - visudo: /etc/sudoers.tmp unchanged [SOLVED]

#31 2010-09-07 15:57:11

Re: visudo no longer runs - visudo: /etc/sudoers.tmp unchanged [SOLVED]

#32 2010-09-07 15:58:41

Re: visudo no longer runs - visudo: /etc/sudoers.tmp unchanged [SOLVED]

#33 2010-09-07 20:19:16

Re: visudo no longer runs - visudo: /etc/sudoers.tmp unchanged [SOLVED]

#34 2010-09-08 06:05:17

Re: visudo no longer runs - visudo: /etc/sudoers.tmp unchanged [SOLVED]

#35 2010-09-08 08:45:47

Re: visudo no longer runs - visudo: /etc/sudoers.tmp unchanged [SOLVED]

#36 2010-09-08 14:01:20

Re: visudo no longer runs - visudo: /etc/sudoers.tmp unchanged [SOLVED]

#37 2010-09-08 14:09:59

Re: visudo no longer runs - visudo: /etc/sudoers.tmp unchanged [SOLVED]

#38 2010-09-08 15:02:57

Re: visudo no longer runs - visudo: /etc/sudoers.tmp unchanged [SOLVED]

#39 2010-09-09 06:00:45

Re: visudo no longer runs - visudo: /etc/sudoers.tmp unchanged [SOLVED]

#40 2010-09-09 08:55:33

Re: visudo no longer runs - visudo: /etc/sudoers.tmp unchanged [SOLVED]

#41 2010-09-10 00:08:39

Re: visudo no longer runs - visudo: /etc/sudoers.tmp unchanged [SOLVED]

#42 2010-09-10 09:21:58

Re: visudo no longer runs - visudo: /etc/sudoers.tmp unchanged [SOLVED]

#43 2010-09-10 20:02:24

Re: visudo no longer runs - visudo: /etc/sudoers.tmp unchanged [SOLVED]

#44 2010-09-10 20:17:50

Re: visudo no longer runs - visudo: /etc/sudoers.tmp unchanged [SOLVED]

#45 2010-09-10 20:56:26

Re: visudo no longer runs - visudo: /etc/sudoers.tmp unchanged [SOLVED]

#46 2010-09-10 21:14:57

Re: visudo no longer runs - visudo: /etc/sudoers.tmp unchanged [SOLVED]

#47 2010-09-11 00:23:00

Re: visudo no longer runs - visudo: /etc/sudoers.tmp unchanged [SOLVED]

#48 2010-09-11 19:35:37

Re: visudo no longer runs - visudo: /etc/sudoers.tmp unchanged [SOLVED]

#49 2010-09-11 21:33:02

Re: visudo no longer runs - visudo: /etc/sudoers.tmp unchanged [SOLVED]

Board footer