Subject: bug#73100: Regarding a bug in suspend-emacs

From: Eli Zaretskii <[email-masked]>
Date: Sat, 07 Sep 2024 19:29:53 +0300

> From: Riza Dindir <[email-masked]>
> Date: Sat, 7 Sep 2024 19:11:02 +0300
> Cc: [email-masked]
> 
> I am new to the code base, and it was just a suggestion to check for the ioctl call for any failures and take
> precautions, maybe inform the user of the issue that the suspend-emacs command did not run correctly. Since
> the command was not printing out anything when called with 'M-: (suspend-emacs "pwd")' I was not sure what
> was happening.

I was asking for your user's expectations, not how to do that in the
code.

> For users that use the linux kernel 6.2+ the ioctl command does not work correctly. When the STUFFSTRING is
> passed to the suspend-emacs command, it does nothing. The problem with kernel 6.2+ is that it requires
> CAP_SYS_ADMIN capability (https://www.man7.org/linux/man-pages/man2/TIOCSTI.2const.html).
> 
> In the code at some point suspend-emacs command calls stuff_char, which uses ioctl (code snippet below, from
> https://git.savannah.gnu.org/cgit/emacs.git/tree/src/sysdep.c#n403). The ioctl call fails. But in the code there is
> no check for that, that might confuse people that use linux kernel 6.2+. I wanted to use suspend-emacs with
> "pwd" as the string (as shown in the example in the documentation in
> https://www.gnu.org/software/emacs/manual/html_node/elisp/Suspending-Emacs.html). But the "pwd" command
> was not displaying anything. Because it was not being sent/stuffed to the superior process.

Does ioctl return -1 in that case?  (I don't have access to a system
where it fails, it works for me on GNU/Linux.)

> Adding an error check would be one of the solutions.

Assuming we can check that (see above), the question is what to do if
we do detect a failure.

> The other solution might be to add a piece of information to the documentation for suspend-emacs, (and
> maybe to the documentation string for suspend-emacs) regarding this problem. So that people that use linux
> kernel 6.2+ would be aware of this issue.

That is already done, except that the documentation cannot be too
specific regarding when and under what conditions it could happen.