gotop fails on some Android devices due to /dev/tty issue, when run with `sudo`, alias as a fix

[Manamama]

gotop fails on some Android devices due to /dev/tty issue

Problem Description:

gotop fails to run on some Android devices when run with sudo, while it works on other, almost identical devices. The failure is caused by the error open /dev/tty: no such device or address.

Steps to Reproduce:

1. On an affected Android device with Termux and Magisk, run gotop with sudo:

   sudo gotop
   

2. The command fails with the error open /dev/tty: no such device or address.

Error Messages:

errors encountered; check the log file /data/data/com.termux/files/home/.suroot/.cache/gotop/errors.log

The log file contains:

open /dev/tty: no such device or address

Investigation:

• The issue is not related to partuuid or smartctl errors, as these are just warnings and they also appear on the working device.
• The issue only happens when gotop is run with sudo.
• gotop needs sudo to get CPU information.
• The issue is not present on another, almost identical Android device.
• The working device has more Magisk modules installed than the failing device, including BuiltIn-BusyBox and NoProcStatRestriction, which might be related to the issue.

Workaround:

The following workaround allows gotop to run with sudo:

alias gotop='sudo script -q -c "gotop --no-statusbar"'

This workaround uses the script command to create a pseudo-terminal, which satisfies gotop's requirement for a tty.

Theory:

The problem is likely caused by a difference in the sudo or tty configuration between the two devices. The failing device might have a stricter sudo configuration that does not allocate a pseudo-terminal by default. The working device might have a more permissive configuration, or one of the extra Magisk modules might be changing the tty behavior.

Suggested Solution:

It would be beneficial if gotop could be run with sudo in a non-interactive environment without requiring a tty. This would improve the user experience on Android devices and other environments where a tty is not always available.

Related, legacy: #258 , as it seems to have been solved with some update.

Ref:

~/.../GitHub/gotop $ /data/data/com.termux/files/usr/bin/gotop --version
gotop v4.2.0 (20250909T222420)
~/.../GitHub/gotop $ 

or in the git cloned and compiled:

 git remote -v
origin	https://git.sr.ht/~ser/gotop (fetch)
origin	https://git.sr.ht/~ser/gotop (push)
~/.../GitHub/gotop $ 

with blank version number:

~/.../GitHub/gotop $ ./gotop  -v
gotop 0.0.0 (Hadean)
~/.../GitHub/gotop $

[Manamama]

Aha, for the record, on both Droids:

~ $ sudo file  /dev/tty

/dev/tty: character special (5/0)
~ $ 

But on the "good Droid" , where sudo gotop works out of the box, this weirdness :

~ $ sudo file  /dev/tty

/dev/tty: character special (5/0)
~ $ tty
/dev/pts/32
~ $ sudo tty

/debug_ramdisk/.magisk/pts/1
~ $ 

Gemini AI has this theory:

The working device's sudo creates a new pseudo-terminal via Magisk (/debug_ramdisk/.magisk/pts/1), while the failing device's does not. My theory is a Magisk module on the working device, likely Built-in-BusyBox, alters su's behavior. To fix this, you'll need to install that module on the failing device. If that doesn't work, we can try the other extra modules one by one. I'm confident this explains the problem.