A few days ago, a problem was encountered. Calling another shell in a terminal was always unenforceable. Later, the wrong information was captured as sudo: sorry, you must have a TTY to run sudo, and later, it was learned online that the following can be solved:
1. Edit/etc/sudoers
1) defaults requirement is changed to “defaults requirement”, which means that the control terminal is not required.
2) defaults requirement, modify to Defaults:nobody !requiretty Indicates that only nobody users do not need to control the terminal.
If it is modified to defaults: nobody! Requirement, it means that only the nobody group does not need to control the terminal.
In fact, just comment out the defaults requirement. Indicates that the terminal is not opened during execution. However, some shells must have a terminal to execute. This is obviously not going to work. Later, I found another piece of article. The following is transcribed for future use only.
Some programs/scripts may be executed in the environment without controlling the terminal (for example, when the system starts the service, the program started by daemon,
or setsid, etc.), but this program may need to control the terminal. How about this?
for example, we start a service when Linux starts, But there is a program in the middle (the old systemtap) that uses sudo
but sudo needs to control the terminal (of course, you can modify sudo’s configuration file, but it’s not friendly to users)
example: (the program started by setsid will lose control of the terminal)
# setsid sudo LS
sudo: sorry, you must have a TTY to run sudo
(if your system doesn’t output this sentence, That is, the sudo configuration file of your system allows sudo to open the control terminal when there is no control interrupt:
# set Sid head – C 0/dev/TTY
head: cannot open ‘/ dev/TTY’ for reading: no such device or address
to solve this problem, So you should use the program that can create (pseudo) control terminal to start your program, such as: script, expect
such as:
# setsid script – C “sudo LS)/dev/null
or:
# setsid expect – C ‘SPAD sudo LS; expect’
# open the control terminal successfully:
# setsid script – C ‘head – C 0/dev/TTY’/dev/null
# setsid expect – C ‘SPAD head – C 0/dev/TTY; expect’
However, there is a strange bug in the combination of setsid and script. I’ve been using a lot of decompression during this period.
this is overqualified for script and expect.