Philip Guenther <guenther <at> gmail.com> writes:
> This is where Remco's response comes into play. As described on the
> tty(4)/cua(4) manpage, /dev/ttyU* blocks on open until the external
> device signals that it's active via some hardware signal (DTR, iirc).
> If you want to initiate an outgoing connection to a potentially
> inactive device, use the matching /dev/cuaU* device.
OK, I've got it to work using a /dev/cua* device. I still have problems with
processes not exiting though. Since this machine has real com ports, I also
made a cable that is attached to cua01 (no USB involved).
This little Perl script shows the problem:
#!/usr/bin/perl -w
$|=1;
close(STDIN) or die;
open(STDIN,"</dev/cua01");
system("/bin/stty 9600 sane parenb -parodd crtscts cs7 igncr");
system("/bin/stty");
while (my $line = <>) {
print $line;
}
I run it using ktrace:
$ ktrace -i ./try.pl
speed 9600 baud;
lflags: echoe echoke echoctl
iflags: igncr
cflags: cs7 parenb crtscts
/XMX5XMXABCE000035164
0-0:96.1.1(31333031333735352020202020202020)
1-0:1.8.1(02932.937*kWh)
[ ... output snipped ...]
It shows as follows in the output of ps:
$ ps
PID TT STAT TIME COMMAND
15727 p0 Ss 0:00.01 -ksh (ksh)
13444 p0 S+ 0:00.02 kdump -l -T
26314 p1 Ss 0:00.00 -ksh (ksh)
13670 p1 S+ 0:00.01 /usr/bin/perl -w ./try.pl
6996 p2 Ss 0:00.00 -ksh (ksh)
29731 p2 R+/1 0:00.00 ps
Then when I kill it, I get this:
$ kill 13670
$ ps
PID TT STAT TIME COMMAND
15727 p0 Is 0:00.01 -ksh (ksh)
13444 p0 S+ 0:00.02 kdump -l -T
26314 p1 Is 0:00.00 -ksh (ksh)
13670 p1 SE+ 0:00.01 (perl)
6996 p2 Ss 0:00.00 -ksh (ksh)
13352 p2 R+/1 0:00.00 ps
... and after a while, this:
$ ps
PID TT STAT TIME COMMAND
15727 p0 Is 0:00.01 -ksh (ksh)
13444 p0 S+ 0:00.02 kdump -l -T
26314 p1 Is 0:00.00 -ksh (ksh)
13670 p1 IE+ 0:00.01 (perl)
6996 p2 Ss 0:00.00 -ksh (ksh)
23612 p2 R+/1 0:00.00 ps
The terminal on which the Perl script was running didn't return the prompt.
The script was also no longer running, because it didn't display new data
coming from cua00 anymore.
The last few lines from ktrace.out are:
13670 perl 1389283736.782851 RET write 2
13670 perl 1389283736.782855 CALL read(0,0x10dbb9977000,0x2000)
13670 perl 1389283738.376985 PSIG SIGTERM SIG_DFL
The read normally blocks for 10 seconds, because that is the interval the
meter sends it data. The kill happened while this read was waiting for data.
I am now no longer able to terminate the process. Disconnecting its terminal
just gives:
$ ps
PID TT STAT TIME COMMAND
15727 p0 Is 0:00.01 -ksh (ksh)
13444 p0 S+ 0:00.02 kdump -l -T
13670 p1- IE 0:00.01 (perl)
6996 p2 Ss 0:00.00 -ksh (ksh)
32590 p2 R+/1 0:00.00 ps
Killing it with -9 also does not work.
cua01 is still busy though:
$ stty -f /dev/cua01
stty: /dev/cua01: Device busy
The only way to get rid of the process is to reboot the system.
Am I doing anything wrong here? I expected the process to just exit and
release cua01 after I killed it.
Regards,
Jurjen Oskam
