spurious error return of -1 at end of successful invocation

[u-root]

spurious error return of -1 at end of successful invocation

[brho]

might be similar to what i get. i can get a return of 1 by doing a ctl-c before ctl-d when running bash.

This is with just hitting ctl-d, and i get no error:

$ ./cpu TARGET bash --norc --noprofile
bash-5.1# 
exit

This is with hitting ctl-c, then ctl-d

$ ./cpu TARGET bash --norc --noprofile
bash-5.1# ^C
bash-5.1# 
exit
2022/03/04 16:14:28 CPUD(as remote):exit status 130
2022/03/04 16:14:28 SSH error Process exited with status 1
                                                          $

[brho]

do you still get this one? i still get my version of it, every time. i can try debugging it too.

[brho]

ok for my specific thing, that's actually not a bug. the shell actually returns 130, just as the output says. without using cpu at all:

brho@gnomeregan ~/ $ sh
sh-5.1$ 
exit
brho@gnomeregan ~/ $ echo $?
0
brho@gnomeregan ~/ $ sh
sh-5.1$ ^C
sh-5.1$ 
exit
brho@gnomeregan ~/ $ echo $?
130

wtf is 130? that's SIGINT + 128

why is that the return value of sh? (which is bash btw, on my system). because it looks like when bash exits, its exit status is the status of its last command. that's certainly the behavior of bash scripts, and it makes sense they do it for the shell process itself too.

e.g.

brho@gnomeregan ~/ $ sh
sh-5.1$ ls /no-such/file
ls: cannot access '/no-such/file': No such file or directory
sh-5.1$ 
exit
brho@gnomeregan ~/ $ echo $?
2
brho@gnomeregan ~/ $ sh
sh-5.1$ echo no-way > /etc/passwd
sh: /etc/passwd: Permission denied
sh-5.1$ 
exit
brho@gnomeregan ~/ $ echo $?
1
brho@gnomeregan ~/ $ sh
sh-5.1$ ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 Feb 28 12:25 /dev/null
sh-5.1$ 
exit
brho@gnomeregan ~/ $ echo $?
0

also, this looks different than your bug, since you're not using a shell.

anyway, what's the fix? one option would be to ignore all errors that came from shells. perhaps in cpud handler(), isPty case, don't check the error value? though that's less than ideal, since i think that's the cpud --remote command, not the actual shell. btw, at this point, cpud has lost the error code. i.e. instead of 130, it thinks it is '1'. and not only that, but the string "exit status 1"

2022/03/10 12:33:36 wait for /usr/local/bin/cpud -remote -bin cpud -port9p 39175 sh
2022/03/10 12:33:36 cmd exit status 1 returns with /usr/local/bin/cpud -remote -bin cpud -port9p 39175 sh exit status 1
2022/03/10 12:33:36 CPUD:child exited with  exit status 1

that "cmd exit status 1" is "cmd %v", err. i think you might want the args swapped to that printf. (cmd, err, cmd.ProcessState. not err, cmd, cmd.ProcessState)

is there any way to know if we're in a shell inside runRemote()? if not, maybe we need an arg from cpud to cpud --remote, e.g. "--ignore-cmd-error", so we can suppress this.