Multiple programs accessing serial device - Linux

This is a discussion on Multiple programs accessing serial device - Linux ; Hi, I'm writing a program to cummunicate with a serial device. It's working, open("/dev/ttyS0", O_RDWR | O_NO_CTTY), write to it, read from it, everythings fine, but: While my program is accessing /dev/ttyS0 other programs can do so as well, but ...

+ Reply to Thread
Results 1 to 18 of 18

Thread: Multiple programs accessing serial device

  1. Multiple programs accessing serial device

    Hi,
    I'm writing a program to cummunicate with a serial device. It's working, open("/dev/ttyS0", O_RDWR | O_NO_CTTY), write to it, read from it, everythings fine, but:

    While my program is accessing /dev/ttyS0 other programs can do so as well, but I don't want that.

    How can I block other programs from accessing /dev/ttyS0 while I want to use it? I looked in the glibc documentation and tried the O_SHLOCK and O_EXLOCK flags on open, but they don't seem to work on Linux (compile error).

    Thank you for your answers,

    Christoph

  2. Re: Multiple programs accessing serial device

    On 2008-10-26, Christoph Kobe wrote:

    > While my program is accessing /dev/ttyS0 other programs can do
    > so as well, but I don't want that.
    >
    > How can I block other programs from accessing /dev/ttyS0 while
    > I want to use it?


    Traditionally, programs controlled access to serial ports using
    lockfiles.

    --
    Grant


  3. Re: Multiple programs accessing serial device

    On Sun, 26 Oct 2008 08:49:02 -0500
    Grant Edwards wrote:

    > Traditionally, programs controlled access to serial ports using
    > lockfiles.


    What do you mean by lockfiles? I tried to lock the file ("/dev/ttyS0") using this:

    ----
    int fd, return_value;
    struct flock lockp;

    fd = open("/dev/ttyS0", O_RDWR | O_NOCTTY);
    // some error checking here, but open works fine

    lockp.l_type = F_WRLCK; // Also tried F_RDLCK
    lockp.l_whence = SEEK_SET; // Also tried SEEK_CUR and SEEK_END
    lockp.l_start = 0; // Also tried 1
    lockp.l_len = 0; // Also tried 5
    lockp.l_pid = 0; // This shouldn't matter anyway

    return_value = fcntl(fd, F_SETLK, lockp);
    ----

    But the call to fcntl fails, return_value gets set to -1, errno to 29 and perror tells me "Bad address".

    What's wrong here?

  4. Re: Multiple programs accessing serial device

    On 2008-10-26, Christoph Kobe wrote:
    > Grant Edwards wrote:
    >
    >> Traditionally, programs controlled access to serial ports using
    >> lockfiles.

    >
    > What do you mean by lockfiles?


    http://en.wikipedia.org/wiki/File_locking
    http://www.linux.org/docs/ldp/howto/...-HOWTO-14.html
    http://docs.freebsd.org/info/uucp/uu...ock_Files.html


    > I tried to lock the file ("/dev/ttyS0") using this:
    >
    > ----
    > int fd, return_value;
    > struct flock lockp;
    >
    > fd = open("/dev/ttyS0", O_RDWR | O_NOCTTY);
    > // some error checking here, but open works fine
    >
    > lockp.l_type = F_WRLCK; // Also tried F_RDLCK
    > lockp.l_whence = SEEK_SET; // Also tried SEEK_CUR and SEEK_END
    > lockp.l_start = 0; // Also tried 1
    > lockp.l_len = 0; // Also tried 5
    > lockp.l_pid = 0; // This shouldn't matter anyway
    >
    > return_value = fcntl(fd, F_SETLK, lockp);
    > ----
    >
    > But the call to fcntl fails, return_value gets set to -1, errno to 29 and perror tells me "Bad address".
    >
    > What's wrong here?


    Dunno. I've never seen anybody try to lock a character device
    file like that.

    --
    Grant


  5. Re: Multiple programs accessing serial device

    On Sun, 26 Oct 2008 23:20:49 -0500
    Grant Edwards wrote:

    > http://en.wikipedia.org/wiki/File_locking
    > http://www.linux.org/docs/ldp/howto/...-HOWTO-14.html
    > http://docs.freebsd.org/info/uucp/uu...ock_Files.html


    I had read the Wikipedia article before, but reading through the
    second article points out the main problem:

    "Note that if a process insists on using a device that is locked,
    it may ignore the lockfile and use the device anyway."

    This is not what I am looking for. I want to restict access to
    my programm and prevent other programs from using the device.
    I dont't want to tell them "please don't use it", I want them
    to get an "access denied".

    Is that possible for /dev/ttyS0 ?

    > Dunno. I've never seen anybody try to lock a character device
    > file like that.


    Maybe it's not supposed to be locked like that ?!

  6. Re: Multiple programs accessing serial device

    Christoph Kobe writes:

    > On Sun, 26 Oct 2008 23:20:49 -0500
    > Grant Edwards wrote:
    >
    >> http://en.wikipedia.org/wiki/File_locking
    >> http://www.linux.org/docs/ldp/howto/...-HOWTO-14.html
    >> http://docs.freebsd.org/info/uucp/uu...ock_Files.html

    >
    > I had read the Wikipedia article before, but reading through the
    > second article points out the main problem:
    >
    > "Note that if a process insists on using a device that is locked,
    > it may ignore the lockfile and use the device anyway."
    >
    > This is not what I am looking for. I want to restict access to
    > my programm and prevent other programs from using the device.
    > I dont't want to tell them "please don't use it", I want them
    > to get an "access denied".
    >
    > Is that possible for /dev/ttyS0 ?


    It's possible there's a way, but I wouldn't be surprised if not.

    This would run counter to the usual Unix philosophy that multiple
    programs needing the same resource are expected to work it out among
    themselves, rather than having the operating system give access to one
    and deny the others. Locking mechanisms may be provided to facilitate
    this, but usually they are advisory, and it's up to all parties to make
    sure that they use those mechanisms consistently.

    This has pros and cons. On the one hand it does allow a misbehaving
    program to break things. But on the other hand, if you think about it,
    having these sort of mandatory mechanisms leads to a kind of arms race.
    Perhaps you have a misbehaving program that doesn't respect your locks,
    so you want a locking mechanism that forbids everyone else from using
    the resource. But now suppose some misbehaving program sets such a lock
    on a file that you want to get at. So you need a way to override a
    lock. But a misbehaving program might use such overrides
    inappropriately. So now you need a lock that can't be overridden. Et
    cetera, et cetera. (There are ways out of this trap, sort of, but they
    tend not to be very nice.) The voluntary scheme also has the advantage
    of being more flexible: the programmer can decide for herself what is
    required, and it needn't conform to OS-imposed rules which might not be
    appropriate in a certain case.

    The sort of access control that Unix does offer is the permission
    system. For instance, if you change the permissions on the device so
    that only root (or whatever user your program runs as) can read or write
    the device, then other users will be denied access, as you desire. It
    won't lock out other programs running as root (or the same user), but
    this goes to another tenet of Unix philosophy: each user is assumed to
    be in control of the processes they run. If it's doing something you
    don't want, but otherwise have permission to do, the OS won't stop it:
    it's up to you to kill it, and not run it anymore until you've fixed it
    (*). This applies also to root, who has permission to do almost
    anything: root's processes can't restrict each other's behavior, and
    it's up to the administrator to make sure they work in a desirable way,
    and fix them if they don't.

    So according to this philosophy, the way to handle your situation is
    this: ensure that other users don't have access to the device in
    question, and use the agreed-upon advisory locking mechanisms (lock
    files in /var/lock in this case). If other programs you run are
    well-behaved, they will respect this. If they aren't well-behaved, then
    don't run them, or fix them so that they are. The OS might provide
    tools to help you detect this situation and track down the offender, but
    you shouldn't expect it to "save you from yourself".

    Again, this philosopy has pros and cons, but it's pretty well ingrained
    in Unix and in general you're not going to get very far trying to change
    it.

    So maybe you should think some more about why you want to do this, what
    problem you're really trying to solve, and whether there is another
    solution more in keeping with this philosophy.

    >> Dunno. I've never seen anybody try to lock a character device
    >> file like that.

    >
    > Maybe it's not supposed to be locked like that ?!


    Yeah, AFAIK the convention for locking devices is via creating device
    files in /var/lock. flock()/fcntl() are for regular files.

  7. Re: Multiple programs accessing serial device

    On 2008-10-27, Christoph Kobe wrote:
    > On Sun, 26 Oct 2008 23:20:49 -0500
    > Grant Edwards wrote:
    >
    >> http://en.wikipedia.org/wiki/File_locking
    >> http://www.linux.org/docs/ldp/howto/...-HOWTO-14.html
    >> http://docs.freebsd.org/info/uucp/uu...ock_Files.html

    >
    > I had read the Wikipedia article before, but reading through the
    > second article points out the main problem:
    >
    > "Note that if a process insists on using a device that is locked,
    > it may ignore the lockfile and use the device anyway."
    >
    > This is not what I am looking for. I want to restict access to
    > my programm and prevent other programs from using the device.
    > I dont't want to tell them "please don't use it", I want them
    > to get an "access denied".
    >
    > Is that possible for /dev/ttyS0 ?


    From what I can tell by examining the source code for the tty
    driver, it looks like you might want to try the TIOCEXCL ioctl.

    --
    Grant Edwards grante Yow! You were s'posed
    at to laugh!
    visi.com

  8. Re: Multiple programs accessing serial device

    On 2008-10-26, Christoph Kobe wrote:
    >
    > I'm writing a program to cummunicate with a serial device.
    > It's working, open("/dev/ttyS0", O_RDWR | O_NO_CTTY), write to
    > it, read from it, everythings fine, but:
    >
    > While my program is accessing /dev/ttyS0 other programs can do
    > so as well, but I don't want that.
    >
    > How can I block other programs from accessing /dev/ttyS0 while
    > I want to use it? I looked in the glibc documentation and
    > tried the O_SHLOCK and O_EXLOCK flags on open, but they don't
    > seem to work on Linux (compile error).


    I don't see either of those options on the open(2) man page.

    --
    Grant Edwards grante Yow! Do you like "TENDER
    at VITTLES"?
    visi.com

  9. Re: Multiple programs accessing serial device

    On 2008-10-27, Grant Edwards wrote:
    > On 2008-10-27, Christoph Kobe wrote:
    >>
    >> "Note that if a process insists on using a device that is locked,
    >> it may ignore the lockfile and use the device anyway."
    >>
    >> This is not what I am looking for. I want to restict access to
    >> my programm and prevent other programs from using the device.
    >> I dont't want to tell them "please don't use it", I want them
    >> to get an "access denied".
    >>
    >> Is that possible for /dev/ttyS0 ?

    >
    > From what I can tell by examining the source code for the tty
    > driver, it looks like you might want to try the TIOCEXCL ioctl.


    NB: it looks like that "lock" is only enforced if the process
    calling open() doesn't have the sys_admin capability.

    --
    Grant Edwards grante Yow! Sometime in 1993
    at NANCY SINATRA will lead a
    visi.com BLOODLESS COUP on GUAM!!

  10. Re: Multiple programs accessing serial device

    Nate Eldredge writes:

    > The sort of access control that Unix does offer is the permission
    > system. For instance, if you change the permissions on the device so
    > that only root (or whatever user your program runs as) can read or write
    > the device, then other users will be denied access, as you desire. It
    > won't lock out other programs running as root (or the same user), but
    > this goes to another tenet of Unix philosophy: each user is assumed to
    > be in control of the processes they run. If it's doing something you
    > don't want, but otherwise have permission to do, the OS won't stop it:
    > it's up to you to kill it, and not run it anymore until you've fixed it
    > (*). This applies also to root, who has permission to do almost
    > anything: root's processes can't restrict each other's behavior, and
    > it's up to the administrator to make sure they work in a desirable way,
    > and fix them if they don't.


    I left out my footnote:

    (*) I think this owes something to Unix's origins as an environment for
    programmers. Each user would ordinarily have the source to all their
    own programs, and so could fix any undesired behavior at that level and
    then recompile. By extension, the administrator would be expected to
    have the complete source for the operating system and all system
    programs. This idea loses something when you have closed-source
    software and users (and admins) who aren't skilled programmers, and has
    a lot to do with the close connection to this day between open-source
    software and Unix-like operating systems.

  11. Re: Multiple programs accessing serial device

    On Mon, 27 Oct 2008 13:05:50 -0700
    Nate Eldredge wrote:

    > Again, this philosopy has pros and cons, but it's pretty well ingrained
    > in Unix and in general you're not going to get very far trying to change
    > it.
    >
    > So maybe you should think some more about why you want to do this, what
    > problem you're really trying to solve, and whether there is another
    > solution more in keeping with this philosophy.


    > (*) I think this owes something to Unix's origins as an environment for
    > programmers. Each user would ordinarily have the source to all their
    > own programs, and so could fix any undesired behavior at that level and
    > then recompile. By extension, the administrator would be expected to
    > have the complete source for the operating system and all system
    > programs. This idea loses something when you have closed-source
    > software and users (and admins) who aren't skilled programmers, and has
    > a lot to do with the close connection to this day between open-source
    > software and Unix-like operating systems.


    Thanks for your explaination. I wans't quite aware of the philosophy
    behind it. I have to admint that I don't really have a problem that
    couldn't be solved with the lockfiles approach. I still have enough
    control over the programs running on that linux box, so lockfiles will do
    fine. Using file permissions for the device would also be convenient in
    my case, since the program is not run by a user but as a daemon started
    via crontab.
    But on the other hand I'm coming from the windows-world where I see
    little cooperation bewtween programs and where in some cases it's
    necessary to exclude other programs run by the same user from acessing
    the same device. So it turns out to me, that myquestion was rather about
    the principle behind it, which is quite different for the two systems.

    Thanks again,

    Christoph

  12. Re: Multiple programs accessing serial device

    On 2008-10-29, Christoph Kobe wrote:

    > But on the other hand I'm coming from the windows-world where I see
    > little cooperation bewtween programs and where in some cases it's
    > necessary to exclude other programs run by the same user from acessing
    > the same device.


    You should be able to do that under Unix by using the TIOCEXCL
    ioctl.

    --
    Grant Edwards grante Yow! Here we are in America
    at ... when do we collect
    visi.com unemployment?

  13. Re: Multiple programs accessing serial device

    Christoph Kobe writes:

    > On Mon, 27 Oct 2008 13:05:50 -0700
    > Nate Eldredge wrote:
    >
    >> Again, this philosopy has pros and cons, but it's pretty well ingrained
    >> in Unix and in general you're not going to get very far trying to change
    >> it.
    >>
    >> So maybe you should think some more about why you want to do this, what
    >> problem you're really trying to solve, and whether there is another
    >> solution more in keeping with this philosophy.

    >
    >> (*) I think this owes something to Unix's origins as an environment for
    >> programmers. Each user would ordinarily have the source to all their
    >> own programs, and so could fix any undesired behavior at that level and
    >> then recompile. By extension, the administrator would be expected to
    >> have the complete source for the operating system and all system
    >> programs. This idea loses something when you have closed-source
    >> software and users (and admins) who aren't skilled programmers, and has
    >> a lot to do with the close connection to this day between open-source
    >> software and Unix-like operating systems.

    >
    > Thanks for your explaination. I wans't quite aware of the philosophy
    > behind it. I have to admint that I don't really have a problem that
    > couldn't be solved with the lockfiles approach. I still have enough
    > control over the programs running on that linux box, so lockfiles will do
    > fine. Using file permissions for the device would also be convenient in
    > my case, since the program is not run by a user but as a daemon started
    > via crontab.
    > But on the other hand I'm coming from the windows-world where I see
    > little cooperation bewtween programs and where in some cases it's
    > necessary to exclude other programs run by the same user from acessing
    > the same device. So it turns out to me, that myquestion was rather about
    > the principle behind it, which is quite different for the two systems.


    You're welcome. I recently had a conversation with a programmer with a
    Windows background who was working on a project on Unix, which had
    several instances of his program using the same file. He was amazed to
    learn that Unix would allow more than one process to write to a file at
    the same time. (I on the other hand remember being amazed when I found
    that Windows would not.) So I had an idea as to what you might be
    thinking

  14. Re: Multiple programs accessing serial device

    On 2008-10-29, Nate Eldredge wrote:

    > You're welcome. I recently had a conversation with a
    > programmer with a Windows background who was working on a
    > project on Unix, which had several instances of his program
    > using the same file. He was amazed to learn that Unix would
    > allow more than one process to write to a file at the same
    > time. (I on the other hand remember being amazed when I found
    > that Windows would not.)


    I remember being stunned when I found out that on windows you
    can't even read a file to which somebody else is writing. I
    had written a program that was writing messages to a log file,
    and I just couldn't believe that I wasn't allowed to read the
    messages until after the program closed the file. [I still
    have no idea why there should be such a limitation.]

    --
    Grant Edwards grante Yow! I'm a fuschia bowling
    at ball somewhere in Brittany
    visi.com

  15. Re: Multiple programs accessing serial device

    On Wed, 29 Oct 2008 11:34:24 -0500
    Grant Edwards wrote:

    > On 2008-10-29, Nate Eldredge wrote:
    >
    > > You're welcome. I recently had a conversation with a
    > > programmer with a Windows background who was working on a
    > > project on Unix, which had several instances of his program
    > > using the same file. He was amazed to learn that Unix would
    > > allow more than one process to write to a file at the same
    > > time. (I on the other hand remember being amazed when I found
    > > that Windows would not.)

    >
    > I remember being stunned when I found out that on windows you
    > can't even read a file to which somebody else is writing. I
    > had written a program that was writing messages to a log file,
    > and I just couldn't believe that I wasn't allowed to read the
    > messages until after the program closed the file. [I still
    > have no idea why there should be such a limitation.]


    I remember beeing stunned when I first learned about all the
    advantages (and some disadvantages) of my linux system. I remember
    installing a rather early version of it (kernel 2.0.???), no GUI,
    sitting in front of the console and having no idea what to do with
    it :-)
    But now I'm happy with it running 24/7, doing lots of things that
    are amazing and I did not pay a single euro for the software.

    On 2008-10-29, Christoph Kobe wrote:

    > But on the other hand I'm coming from the windows-world where I see
    > little cooperation bewtween programs and where in some cases it's
    > necessary to exclude other programs run by the same user from acessing
    > the same device.


    You should be able to do that under Unix by using the TIOCEXCL
    ioctl.

    Ok, I learnt that I don't need it anymore, but maybe I'll try it anyway ;-)

  16. Re: Multiple programs accessing serial device

    On 2008-10-31, Christoph Kobe wrote:

    >> I remember being stunned when I found out that on windows you
    >> can't even read a file to which somebody else is writing. I
    >> had written a program that was writing messages to a log file,
    >> and I just couldn't believe that I wasn't allowed to read the
    >> messages until after the program closed the file. [I still
    >> have no idea why there should be such a limitation.]

    >
    > I remember beeing stunned when I first learned about all the
    > advantages (and some disadvantages) of my linux system. I remember
    > installing a rather early version of it (kernel 2.0.???), no GUI,
    > sitting in front of the console and having no idea what to do with
    > it :-)


    Why no GUI? I started using Linux in the 0.9x kernel days 15+
    years ago, and X11 worked fine back then (with 8MB of RAM, a
    40MB hard drive, and a "Hercules" monochrome video card).
    Before that I ran another flavor of Unix -- I tried using DOS
    for a while, but it was pretty lame. I tried Windows when it
    came out, and it seemed to be just as broken as DOS.

    >> You should be able to do that under Unix by using the TIOCEXCL
    >> ioctl.

    >
    > Ok, I learnt that I don't need it anymore, but maybe I'll try
    > it anyway ;-)


    If you do try it, let us know if it works. It looks like it
    should do what you want based on my examination of the tty
    driver source code, but I've never tried it.

    --
    Grant Edwards grante Yow! Now I'm concentrating
    at on a specific tank battle
    visi.com toward the end of World
    War II!

  17. Re: Multiple programs accessing serial device

    On Fri, 31 Oct 2008 09:19:50 -0500
    Grant Edwards wrote:

    > Why no GUI? I started using Linux in the 0.9x kernel days 15+
    > years ago, and X11 worked fine back then (with 8MB of RAM, a
    > 40MB hard drive, and a "Hercules" monochrome video card).


    Because at that time I was unable to configure it. I was about 14 years old, had nobody to help me,
    no internet connection and absolutely no idea what to do with linux - so I had not much motivation
    to try anyway. That was with SuSE Linux 4.4. But a few years later I succeeded with SuSE 6.2, which
    was already quite comfortable for a linux at that time. Today I'm using Debian.

  18. Re: Multiple programs accessing serial device

    On Fri, 31 Oct 2008 09:19:50 -0500
    Grant Edwards wrote:

    > >> You should be able to do that under Unix by using the TIOCEXCL
    > >> ioctl.

    > >
    > > Ok, I learnt that I don't need it anymore, but maybe I'll try
    > > it anyway ;-)

    >
    > If you do try it, let us know if it works. It looks like it
    > should do what you want based on my examination of the tty
    > driver source code, but I've never tried it.


    Here is the result: It works!

    lock with TIOCEXCL

    ech bla > /dev/ttyS0
    and
    cat /dev/ttyS0
    both give me:

    Device or resource busy (or whatever it is in english).

    Fine :-)

+ Reply to Thread