Problem locking serial device

[wolf_core]

Hi, I have connected an RS485 to USB converter to TC 3.7.1 + usb-serial- 2.6.33.3-tynycore.tcz  and it was recognised as ttyUSB0, but when i run a daemon ( aurora ) that use /dev/ttyUSB0 i have an error.

Code: [Select]

tc@box :/mnt/sda1/aurora$ ./aurora -a 2 /dev/ttyUSB0
tc@box :/mnt/sda1/aurora$ Problem locking serial device, can't open lock file: /var/lock/LCK..ttyUSB0 for write.
then i try

Code: [Select]

tc@box :/mnt/sda1/aurora$ sudo ./aurora -a 2 /dev/ttyUSB0
tc@box :/mnt/sda1/aurora$ Problem locking serial device, can't write lock file for write: /var/lock/LCK..ttyUSB0.
No such file or directory.
but a LCK..ttyUSB0 file was created in the directory  /var/lock/ with inside a PID identifier.

Can you help me.   Thanks in advance Luca

PS How i can save the output of console to file, i try with  xxxxxx > file.txt but I have only a empty file.txt

[Rich]

Hi wolf_core
I think it is complaining because a lock file already exists. Delete it and try again.

PS How i can save the output of console to file, i try with  xxxxxx > file.txt but I have only a empty file.txt

I take it by xxxxx you mean the aurora command in this case. See if this works:

Code: [Select]

sudo ./aurora -a 2 /dev/ttyUSB0 &> file.txtBased on the error messages, I think you are supposed to use sudo.

[wolf_core]

Hi Rich, i have restarted tiny core and there are no files in /var/lock then I launch

Code: [Select]

tc@box : dmesg  | grep usb
tc@box : Kernel command line: initrd=/boot/tinycore.gz waitusb=5:UUID="786D-025A" tce=UUID="786D-025A" quiet BOOT_IMAGE=/boot/bzImage
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
usbcore: registered new interface driver usb-storage
usbcore: registered new interface driver ums-alauda
usbcore: registered new interface driver ums-cypress
usbcore: registered new interface driver ums-freecom
usbcore: registered new interface driver ums-isd200
usbcore: registered new interface driver ums-jumpshot
usbcore: registered new interface driver ums-karma
usbcore: registered new interface driver ums-onetouch
usbcore: registered new interface driver ums-sddr09
usbcore: registered new interface driver ums-sddr55
usbcore: registered new interface driver ums-usbat
usbcore: registered new interface driver berry_charge
usbcore: registered new interface driver appletouch
usbcore: registered new interface driver bcm5974
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
usb 1-1: new low speed USB device using ohci_hcd and address 2
input: LITEON Technology USB Multimedia Keyboard as /devices/pci0000:00/0000:00:0f.4/usb1/1-1/1-1:1.0/input/input2
generic-usb 0003:046D:C312.0001: input: USB HID v1.10 Keyboard [LITEON Technology USB Multimedia Keyboard] on usb-0000:00:0f.4-1/input0
usb 1-2: new low speed USB device using ohci_hcd and address 3
input: Logitech USB-PS/2 Optical Mouse as /devices/pci0000:00/0000:00:0f.4/usb1/1-2/1-2:1.0/input/input3
generic-usb 0003:046D:C03E.0002: input: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-0000:00:0f.4-2/input0
usb 2-2: new full speed USB device using ohci_hcd and address 2
scsi0 : usb-storage 2-2:1.0
usb 2-1: new full speed USB device using ohci_hcd and address 3
usbcore: registered new interface driver usbserial
usbcore: registered new interface driver usbserial_generic
usbserial: USB Serial Driver core
usb 2-1: pl2303 converter now attached to ttyUSB0
usbcore: registered new interface driver pl2303

the adapter RS485 to USB (pl2303) was recognised and ttyUSB0 was created and seems OK

Code: [Select]

tc@box :/mnt/sda1/aurora$ sudo ./aurora -a 2 /dev/ttyUSB0
tc@box :/mnt/sda1/aurora$ 20120710-23:31:06: aurora: Problem locking serial device, can't write lock file: /var/lock/LCK..ttyUSB0.
No such file or directory

same error :-( , and if I disconnect the adapter the error don't change

Thanks Luca

[Rich]

Hi wolf_core
I decided to take a look at the source code to see if I could figure out what the program is complaining about. I noticed
that the author was misusing the  errno  variable. Open the file called main.c and find the phrase:

Code: [Select]

|| errno_save != 0Remove all three instances of that phrase, not he whole line, just that exact phrase. Recompile the program and
see if it behaves any better.

[wolf_core]

Ty Rich, your patch seems correcting the problem  . Now I try to connect the adapter to RS485 port of  Photovoltaic inverter and I hope i can read the data.

Thanks a lot Luca

[Rich]

Hi wolf_core
Yeah, I had a feeling it might help. Except for a few special cases, errno should not be used to see if an error
occurred, that's what the return value of a function is for. Let us know how you make out.

[Blankman]

Hi wolf_core
I decided to take a look at the source code to see if I could figure out what the program is complaining about. I noticed
that the author was misusing the  errno  variable. Open the file called main.c and find the phrase:
|| errno_save != 0
Remove all three instances of that phrase, not he whole line, just that exact phrase. Recompile the program and
see if it behaves any better.

Rich, explain to me how these three statements, as you put it, was misusing the  errno  variable?

if (bWrite < 0 || errno_save != 0) {
if (bWrite < 0 || errno_save != 0) {
if (bWrite < 0 || errno_save != 0) {

According to the errno(3) - Linux man page

"Valid error numbers are all nonzero; errno is never set to zero by any system call or library function. "

So what the above code is doing is that if fprintf() or fscanf() had a problem bWrite will indicate that and we don't even care what errno is because we don't even check it then at that point. But, if for some reason errno is *not* zero which should not happen without an error actually occurring as indicated by the function(s) return code, I want to know about it. Because that is not right.

I appreciate you bringing this to my attention but I wish wolf_core would have contacted me directly. I fear the problem may lie elsewhere and I'd rather get to the root cause.

What I suspect here is that errno_save is not zero because on the system in question errno is not initialized to zero. I'd like to confirm that and address that. This does not happen on other distributions that I know of.

I'd like to see the debug output from aurora when this occurs by using the -b option as the first option on the line. wolf_core if you can go back to the original code and do that and send it to me directly I'm more then willing to figure out what's going on and make any corrections necessary.

-The author of aurora...

[Blankman]

Or... It looks like that routine and main are the *only* places I forgot to initialize errno to zero *and* the system doesn't do it either. Which would explain why it does not happen in other distributions...

Or... On this distribution for some reason errno *is* set to non-zero if the library call is successful which would not be right either.

Or... By the fact I forgot to initialize it to zero it has what ever that memory location happened to have. But the system should not allow that, that is a big security risk.

Would like to get to the bottom of this.

[curaga]

IIRC no standard requires the system to initialize errno. It's always the app's responsibility.

[wolf_core]

I am sorry to have created this misunderstanding    .
I want to thanks all the members of tiny core forum and also the author of aurora for the aurora daemon. Yes Blankman, I have an original compiled file an i will send the debug result.

Thanks again Luca

[Blankman]

IIRC no standard requires the system to initialize errno. It's always the app's responsibility.

Yeah but it's IMO bad security practices not to initialize variables, allows for memory trolling with crafted use, on a interactive system, not real good. Unless it's being randomized, that's ok too, but that is not known.

Granted my fault for overlooking initializing it in two spots so I'm happy this was brought to my attention, but I would think that since it's from an include file that it would/should maybe be taken of. By the fact I haven't run into it in other distros leads me to believe it is.

Funny thing too, I usually see a compile warning, variable used without being initialized when that occurs, but not in this case. Now that 'm thinking about it that may only be when used in a conditional test and errno is not used that way directly.

[Blankman]

Just did a quick test on openSuse 11.4 in the routine in question and it appears even though I do not initialize it there errno is set to zero.

Looks like Luca had two issues here the open then the write. To get the open error the file pointer would need to be returned NULL.

Luca, when that happened did the /var/lock directory exist?
Also, were you running aurora as root or as a user with lesser privileges?

Looks like you were running it out of the directory it was compiled in before doing a 'make install' which sets the proper privileges on the binary for non root users to use aurora.

I'm going to have to look at that too.

[Rich]

Hi Blankman
In hindsight, "misusing" was a poor choice of words on my part since it suggests intent, and that was not my intent.
From  http://www.kernel.org/doc/man-pages/online/pages/man3/errno.3.html

       The <errno.h> header file defines the integer variable errno, which is set by
       system calls and some library functions in the event of an error to indicate
       what went wrong.  Its value is significant only when the return value of the
       call indicated an error (i.e., -1 from most system calls; -1 or NULL from most
       library functions); a function that succeeds is allowed to change errno.

       Valid error numbers are all nonzero; errno is never set to zero by any system
       call or library function.

Note the phrases  "a function that succeeds is allowed to change errno" and "errno is never set to zero by any system
call or library function". That says that even a successful call to function can return a nonzero value for errno.
There really is no good reason to use errno to test if an error occurred, however, if you really feel you must, you should
probably change the || to && in your if statement.

[wolf_core]

Hi Blankman, yes the directory /var/lock/ exist (no files inside) and i run the daemon with the command

Code: [Select]

tc@box:/mnt/sda1/aurora$ sudo ./aurora -b -a 2 -e /dev/ttyUSB0the daemn return the error but the LCK..ttyUSB0 file was created in the directory  /var/lock/ with inside a PID identifier.
The directory /mnt/sda1/aurora isn't the directory where i compiled the daemon but another directory. I have sent the debug msg by mail.

Thanks Luca

[Rich]

Hi wolf_core

I am sorry to have created this misunderstanding

You did not create any misunderstanding. I emailed a link of this thread to the author and that started an
exchange of ideas.