Re: Anomaly
On 9/20/16 11:04 PM, PePa wrote: > When sourcing this script (version 1), it will print y after receiving > an interrupt, but not in the 2 different versions (2 and 3). > > # version 1 > echo x > sleep 99 > echo y > > # version 2 > echo x; sleep 99 > echo y > > # version 3 > echo x > sleep 99; echo y > > Is this a bug or expected behaviour?? Well, it's definitely a difference between three simple commands and a command list. I think the right behavior is that exhibited by versions 2 and 3: the interrupt causes the execution of the sourced script to halt. I'll take a look at it. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Anomaly
When sourcing this script (version 1), it will print y after receiving an interrupt, but not in the 2 different versions (2 and 3). # version 1 echo x sleep 99 echo y # version 2 echo x; sleep 99 echo y # version 3 echo x sleep 99; echo y Is this a bug or expected behaviour?? Thanks for your attention, Peter
bash and sshd trap anomaly
Hi
In a small bash script we have a trap to cleanup some files when exiting. You
run the script by ssh to the machine in question and execute the script. If
your ssh session dies the trap should trigger and clean up the files as the
script exit but this doesn't happen.
I apologize that the script has excessive echo to a log file, but it makes it
easy to follow. The script is located as /tmp/quirk-plsuper installed on host
XYZ
#!/bin/bash
chars=(A B C D E F G H I J K L M N O P Q R S T U V W X Y Z)
username=plsuper
while grep -q "^$username:" /tmp/passwd; do
username=plsuper
for ((i=0;i<3;i++)); do
username+=${chars[$((RANDOM%${#chars[*]}))]}
done
done
cleanup () {
echo "Trying to cleanup " >> /tmp/trap
grep -v "^$username:" /tmp/passwd > /tmp/passwd.new
echo "Trying to cleanup 1" >> /tmp/trap
grep -v "^$username:" /tmp/shadow > /tmp/shadow.new
echo "Trying to cleanup 2" >> /tmp/trap
mv /tmp/passwd.new /tmp/passwd
echo "Trying to cleanup 3" >> /tmp/trap
mv /tmp/shadow.new /tmp/shadow
echo "Trying to finished" >> /tmp/trap
}
trap "cleanup" EXIT
password=$(awk -F: '/^plsuper:/{print $2}' /tmp/shadow)
echo "$username:x:1001:1001::/home/plsuper:/bin/bash" >> /tmp/passwd
echo "$username:$password:::" >> /tmp/shadow
cat <<-EOF
WARNING! You've exposed the customers system for unauthorized
logins with the account '$username'.
Press enter to remove '$username'.
EOF
read -e
Now ssh to XYZ and execute the script. In a different terminal kill your ssh
client session. If you ssh back to host XYZ you would expect the passwd and
shadow file to be "restored" and the /tmp/trap to contain
Trying to cleanup
Trying to cleanup 1
Trying to cleanup 2
Trying to cleanup 3
Trying to finished
but all I get is
Trying to cleanup
and none of files been "restored".
Granted this is on a home grown embedded Linux environment (bash, version
4.2.50), but when trying the same on my localhost running Ubuntu 14.04 I get a
similar result.
What I do is ssh localhost (ubuntu) and run the script then in another terminal
I kill the ssh client session to localhost. I now get
Trying to cleanup
Trying to cleanup 1
Trying to cleanup 2
so a bit more of the trap is executed it's me thinks some sort of timing or
race going on.
More than a few tries and test later I find a workaround if I change this
section
-
}
trap "cleanup" EXIT
password=$(awk -F: '/^plsuper:/{print $2}' /tmp/shadow)
-
to
-
}
trap "cleanup" EXIT
trap true HUP
password=$(awk -F: '/^plsuper:/{print $2}' /tmp/shadow)
-
It's all working as it should. Only having
-
trap "cleanup" HUP
-
Doesn't work. You can have both EXIT and HUP on the same line and it also works
but the trap gets executed twice which is the expected behaviour.
If you alter the sshd server adding a small 5s sleep in the
session_pty_cleanup2 function in session.c just before pty_release(s->tty);
Then the script/trap is also working just fine without the "trap true HUP"
workaround.
Me guessing now is that ssh is pulling the tty from under the bash script and
it doesn't get the time needed to execute the trap but that doesn't make sense
either since the workaround is working. It's clearly some sort of timing issue
but I can't pin point it.
Looking at the signals coming in to the script if you strace it then it looks
like this:
rt_sigaction(SIGINT, {0x4a0d40, [], SA_RESTORER, 0x7effdbc841e0}, {0x442b60,
[], SA_RESTORER, 0x7effdbc841e0}, 8) = 0
rt_sigaction(SIGHUP, {SIG_DFL, [], SA_RESTORER, 0x7effdbc841e0}, {0x45b240,
[HUP INT ILL TRAP ABRT BUS FPE USR1 SEGV USR2 PIPE ALRM TERM XCPU XFSZ VTALRM
SYS], SA_RESTORER, 0x7effdbc841e0}, 8) = 0
kill(31941, SIGHUP) = 0
rt_sigreturn(0x7cc5)= 0
--- SIGHUP (Hangup) @ 0 (0) ---
Process 31941 detached
Any thoughts?
Jinx
read -t 0 anomaly
I tried to use read -t 0 to check if there is any data on the STDIN or not. The man page said: If timeout is 0, read returns success if input is available on the specified file descriptor, failure otherwise. Maybe I made a mistake but I tested and I got variable results: arpad@terminus ~ $ for(( i=0; i10; i++ )); do echo -n a | read -t 0 ; echo $?; done | sort | uniq -c 10 0 arpad@terminus ~ $ for(( i=0; i10; i++ )); do echo -n a | read -t 0 ; echo $?; done | sort | uniq -c 8 0 2 1 arpad@terminus ~ $ for(( i=0; i10; i++ )); do echo -n a | read -t 0 ; echo $?; done | sort | uniq -c 10 0 I tried this on 2 machines with the same results: GNU bash, version 4.1.5(1)-release (x86_64-pc-linux-gnu) GNU bash, 4.2.45(1)-release (x86_64-pc-linux-gnu) verzió Am I doing something wrong? Did I misunderstand the documentation? Or is there a race condition? Thanks, Arpad Kunszt
Re: read -t 0 anomaly
On Fri, Oct 4, 2013 at 2:20 PM, Kunszt Árpád arpad.kun...@syrius-software.hu wrote: I tried to use read -t 0 to check if there is any data on the STDIN or not. The man page said: If timeout is 0, read returns success if input is available on the specified file descriptor, failure otherwise. Maybe I made a mistake but I tested and I got variable results: arpad@terminus ~ $ for(( i=0; i10; i++ )); do echo -n a | read -t 0 ; echo $?; done | sort | uniq -c 10 0 arpad@terminus ~ $ for(( i=0; i10; i++ )); do echo -n a | read -t 0 ; echo $?; done | sort | uniq -c 8 0 2 1 arpad@terminus ~ $ for(( i=0; i10; i++ )); do echo -n a | read -t 0 ; echo $?; done | sort | uniq -c 10 0 I tried this on 2 machines with the same results: GNU bash, version 4.1.5(1)-release (x86_64-pc-linux-gnu) GNU bash, 4.2.45(1)-release (x86_64-pc-linux-gnu) verzió Am I doing something wrong? Did I misunderstand the documentation? Or is there a race condition? Thanks, Arpad Kunszt There is a race condition, you cannot know if echo will run before read.
Re: read -t 0 anomaly
On 2013. October 4. 14:51:00 Pierre Gaston wrote:
On Fri, Oct 4, 2013 at 2:20 PM, Kunszt Árpád
...
There is a race condition, you cannot know if echo will run before read.
I see, and it's logical. But this stills confuses me.
arpad@terminus ~ $ for(( i=0; i10; i++ )); do echo -n | { sleep 1s; read -t
0; echo $?; } ; done | sort | uniq -c
10 0
I expected that the read will return non-zero in this case. I think it returned
with zero because the STDIN was still open. The docs said read returns success
if input is available on the specified file descriptor, failure otherwise.
There wasn't any data on the file descriptor, it was just open.
Am I still doing something wrong? Or I just misunderstanding the meaning of
input is available term? I'm not a native English speaker (as you can se from
my mails clearly).
Thanks,
Arpad Kunszt
Re: read -t 0 anomaly
On Fri, Oct 4, 2013 at 3:08 PM, Kunszt Árpád
arpad.kun...@syrius-software.hu wrote:
On 2013. October 4. 14:51:00 Pierre Gaston wrote:
On Fri, Oct 4, 2013 at 2:20 PM, Kunszt Árpád
...
There is a race condition, you cannot know if echo will run before read.
I see, and it's logical. But this stills confuses me.
arpad@terminus ~ $ for(( i=0; i10; i++ )); do echo -n | { sleep 1s;
read -t 0; echo $?; } ; done | sort | uniq -c
10 0
I expected that the read will return non-zero in this case. I think it
returned with zero because the STDIN was still open. The docs said read
returns success if input is available on the specified file descriptor,
failure otherwise. There wasn't any data on the file descriptor, it was
just open.
Am I still doing something wrong? Or I just misunderstanding the meaning
of input is available term? I'm not a native English speaker (as you can
se from my mails clearly).
Thanks,
Arpad Kunszt
Most probably read uses and does what the select() call does.
In my man select(2) I have:
more precisely, to see if a read will not block; in particular, a
file descriptor is also ready on end-of-file
and that's what your exemple does, echo opens stdin and then closes it and
read sees and end of file.
no worry about your english..
Re: read -t 0 anomaly
On Fri, Oct 4, 2013 at 3:29 PM, Pierre Gaston pierre.gas...@gmail.comwrote:
On Fri, Oct 4, 2013 at 3:08 PM, Kunszt Árpád
arpad.kun...@syrius-software.hu wrote:
On 2013. October 4. 14:51:00 Pierre Gaston wrote:
On Fri, Oct 4, 2013 at 2:20 PM, Kunszt Árpád
...
There is a race condition, you cannot know if echo will run before read.
I see, and it's logical. But this stills confuses me.
arpad@terminus ~ $ for(( i=0; i10; i++ )); do echo -n | { sleep 1s;
read -t 0; echo $?; } ; done | sort | uniq -c
10 0
I expected that the read will return non-zero in this case. I think it
returned with zero because the STDIN was still open. The docs said read
returns success if input is available on the specified file descriptor,
failure otherwise. There wasn't any data on the file descriptor, it was
just open.
Am I still doing something wrong? Or I just misunderstanding the meaning
of input is available term? I'm not a native English speaker (as you can
se from my mails clearly).
Thanks,
Arpad Kunszt
Most probably read uses and does what the select() call does.
In my man select(2) I have:
more precisely, to see if a read will not block; in particular, a
file descriptor is also ready on end-of-file
and that's what your exemple does, echo opens stdin and then closes it and
read sees and end of file.
no worry about your english..
ah hmm.I spoke a bit too fastread should still not return 0 on end
of file
Re: read -t 0 anomaly
On Fri, Oct 4, 2013 at 3:30 PM, Pierre Gaston pierre.gas...@gmail.comwrote:
On Fri, Oct 4, 2013 at 3:29 PM, Pierre Gaston pierre.gas...@gmail.comwrote:
On Fri, Oct 4, 2013 at 3:08 PM, Kunszt Árpád
arpad.kun...@syrius-software.hu wrote:
On 2013. October 4. 14:51:00 Pierre Gaston wrote:
On Fri, Oct 4, 2013 at 2:20 PM, Kunszt Árpád
...
There is a race condition, you cannot know if echo will run before
read.
I see, and it's logical. But this stills confuses me.
arpad@terminus ~ $ for(( i=0; i10; i++ )); do echo -n | { sleep 1s;
read -t 0; echo $?; } ; done | sort | uniq -c
10 0
I expected that the read will return non-zero in this case. I think it
returned with zero because the STDIN was still open. The docs said read
returns success if input is available on the specified file descriptor,
failure otherwise. There wasn't any data on the file descriptor, it was
just open.
Am I still doing something wrong? Or I just misunderstanding the meaning
of input is available term? I'm not a native English speaker (as you can
se from my mails clearly).
Thanks,
Arpad Kunszt
Most probably read uses and does what the select() call does.
In my man select(2) I have:
more precisely, to see if a read will not block; in particular, a
file descriptor is also ready on end-of-file
and that's what your exemple does, echo opens stdin and then closes it
and read sees and end of file.
no worry about your english..
ah hmm.I spoke a bit too fastread should still not return 0 on
end of file
In fact, it seems read -t0 is only a select and doesn't read anything
$ echo foofile;read -t0 var file ;echo $var #prints nothing
