Prev: 067645 Answers to your Computer question! 63
Next: Processes' memory
From: Jef Driesen on 1 Feb 2010 04:52
On 31/01/2010 15:35, David Schwartz wrote:
> On Jan 29, 5:37 am, Jef Driesen<jefdrie...(a)hotmail.com.invalid>
> wrote:
>
>> One of the reasons why I started this topic is that I don't know how to
>> workaround the issue. Clearing the TIOCEXCL on close only works if the
>> app exits properly. And that doesn't always happen.
>
> Code exactly the behavior you want. If your app terminates abnormally,
> have another application clear the TIOCEXCL flag.

It seems that a separate app to clear the TIOCEXCL flag, when the pty
stays "locked" after an unclear shutdown is about the only option.
Downside is that it will have to run as root.

An alternative option might be not using TIOCEXCL at all in my
development builds (where I want to use pty's) and have it enabled only
for production builds (where I want to use real serial ports). Or as
Rainer suggested, use fcntl locks in my development builds. But I would
like to avoid having to enable/disable code when switching environments.

>> If some malicious program manages to crash my client app, and then opens
>> the pty, that's fine for me. That's not what I want to protect against.
>> I only want to make sure that while my app is communicating, no other
>> process can accidentally mess up the communication by reading/writing
>> data from/to the pty.
>
> Right, you have very, very unusual requirements. It would be strange
> if the system magically just happened to meet them. In fact, the
> system meets the more common set of requirements where you want to
> ensure you have exclusive access to the pty until the pty is released.
>
> Code what you want.

Well, unusual depends a lot on the point of view. I consider the pty
more as a black box. An application only interacts with the device file.
It doesn't know if there is a real serial port or some other process
(for pty's) behind that device file. So why should the behavior be any
different?

As far as I know, I can't even detect the difference between the two, if
I want to special case the pty's in my code.
From: David Schwartz on 1 Feb 2010 17:33
On Feb 1, 1:52 am, Jef Driesen <jefdrie...(a)hotmail.com.invalid> wrote:

> It seems that a separate app to clear the TIOCEXCL flag, when the pty
> stays "locked" after an unclear shutdown is about the only option.
> Downside is that it will have to run as root.

I agree. You are incorrect, it need not run as root. It can, in fact,
run as any user. Clearling the TIOCEXCL flag on a descriptor that was
opened by another process does not require any special privileges. It
simply requires the other process to give you a copy of the
descriptor.

> An alternative option might be not using TIOCEXCL at all in my
> development builds (where I want to use pty's) and have it enabled only
> for production builds (where I want to use real serial ports). Or as
> Rainer suggested, use fcntl locks in my development builds. But I would
> like to avoid having to enable/disable code when switching environments.

Then check whether the device is a pty or a serial port and use
TIOCEXCL only if it's a serial port.

> Well, unusual depends a lot on the point of view. I consider the pty
> more as a black box. An application only interacts with the device file.
> It doesn't know if there is a real serial port or some other process
> (for pty's) behind that device file. So why should the behavior be any
> different?

As I explained, it's not different. In both cases, the "last close"
releases ownership of the resources. A serial port would behave
precisely the same way if you had some other process that also had a
reference to it, just as some other program has a reference to the pty
in the pty case and does not exist in the serial port case. (Perhaps
the solution is to fix that program? Have it close the master side if
the process restarts and create a new pty?)

> As far as I know, I can't even detect the difference between the two, if
> I want to special case the pty's in my code.

Sadly, fstat/st_dev is the only way I know.

DS
From: Jef Driesen on 3 Feb 2010 05:48
On 1/02/2010 23:33, David Schwartz wrote:
> On Feb 1, 1:52 am, Jef Driesen<jefdrie...(a)hotmail.com.invalid> wrote:
>
>> It seems that a separate app to clear the TIOCEXCL flag, when the pty
>> stays "locked" after an unclear shutdown is about the only option.
>> Downside is that it will have to run as root.
>
> I agree. You are incorrect, it need not run as root. It can, in fact,
> run as any user. Clearling the TIOCEXCL flag on a descriptor that was
> opened by another process does not require any special privileges. It
> simply requires the other process to give you a copy of the
> descriptor.

True, but that would need a modification to my app to pass the
descriptor to the unlock app somehow.

I was more thinking about a little unlock app that I can call whenever a
pty appears locked after an unclear shutdown. And that's only possible
as root. For all other users the open() call will fail when the TIOCEXCL
flag is set.

> Perhaps
> the solution is to fix that program? Have it close the master side if
> the process restarts and create a new pty?

I think that should work if the app on the master side can detect when
the client side is closed. I have no idea if that is possible.

>> As far as I know, I can't even detect the difference between the two, if
>> I want to special case the pty's in my code.
>
> Sadly, fstat/st_dev is the only way I know.

I assume you mean st_rdev here? I'm not sure if checking the major/minor
number works well. There seems to be many valid combinations possible.
And I'm not sure it will even work on non linux systems.
From: Moi on 3 Feb 2010 08:28
On Wed, 03 Feb 2010 11:48:17 +0100, Jef Driesen wrote:

> On 1/02/2010 23:33, David Schwartz wrote:

>> Perhaps
>> the solution is to fix that program? Have it close the master side if
>> the process restarts and create a new pty?
>
> I think that should work if the app on the master side can detect when
> the client side is closed. I have no idea if that is possible.

Isn't that is where the SIGHUP was intended for ?
If the kernel generates a sighup for a "broken wire", the master side
could close and reallocate a pty pair, as David suggested.
(that would again cause a "rendez vous" -problem for the client, which was
the underlying reason for the OP ... )

AvK
First  |  Prev  | 
Pages: 1 2 3 4
Prev: 067645 Answers to your Computer question! 63
Next: Processes' memory