Project Home
Project Home		 Documents
Documents		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
QNX Operating System/Discussion/OSTech/Killing shell on serial device/List of Posts
Forum Topic - Killing shell on serial device: (12 Items)
   
Update
Tom Gogh
01/20/2010 11:11 AM
post45546
Killing shell on serial device   
Hi QNX experts,

      Greetings!!
I have hit the wall in finding any elegant solution to kill shell(esh) running on /dev/ser device.
To kill it, at least I need its pid but I am not able to get its pid through any API easily which I can think of.
One way I thought was to use slay command with -t option however, it's not working out for me (always returns error that
 no process with esh name on /dev/ser1 tty)
I think re-starting shell on /dev/ser will be easy through fork or spawn.
but, esh being just binary available, I can't log its pid to any IPC where my application can kill on it.
Are there any POSIX APIs I am missing that could be useful here?

Any perspectives/ideas/suggestions, quite appreciated.

Thanks,
Tom
Neil Schellenberger(deleted)
01/20/2010 11:21 AM
post45547
Re: Killing shell on serial device   
One "simple" trick (albeit one that depends on how tight your control
over the running environment is) would be to create a link to esh with a
distinctive name and always use that when running on /dev/ser.  That
would make slaying by process name reasonably robust.

There are probably dozens of other methods too, but that one has the
advantage of being very simple.

On Wed, 2010-01-20 at 11:11 -0500, Tom Gogh wrote:
> Hi QNX experts,
> 
>       Greetings!!
> I have hit the wall in finding any elegant solution to kill shell(esh) running on /dev/ser device.
> To kill it, at least I need its pid but I am not able to get its pid through any API easily which I can think of.
> One way I thought was to use slay command with -t option however, it's not working out for me (always returns error 
that no process with esh name on /dev/ser1 tty)
> I think re-starting shell on /dev/ser will be easy through fork or spawn.
> but, esh being just binary available, I can't log its pid to any IPC where my application can kill on it.
> Are there any POSIX APIs I am missing that could be useful here?
> 
> Any perspectives/ideas/suggestions, quite appreciated.
> 
> Thanks,
> Tom
> 
> 
>       
> 
> 
> 
> _______________________________________________
> 
> OSTech
> http://community.qnx.com/sf/go/post45546
>
Tom Gogh
01/20/2010 12:11 PM
post45555
Re: Killing shell on serial device   
Neil,
     thanks for your quick reply!

But, I am not feeling comfortable to use slay assuming its implementation can be
not efficient since if I am not terribly wrong, POSIX has no API that gives list of
processes accessing the terminal or file so slay has to iterate over all PIDs and 
check each of its tty matching the input tty.

In meanwhile, I had a thought that the best solution would have been my app1
logging in IPC or non-volatile file its pid or any info that can be read by app2.

So, on this line, one solution can be I just spawn child process which execs to 
esh which will eventually inherit pid of its parent (spawn child created).
With spawn and exec my code will be POSIX portable.

Except I am being new to QNX, I am not sure what are overheads of spawn/exec
model considering its dependency on architecture, MMU/non-MMU, etc.
Neil Schellenberger(deleted)
01/20/2010 12:26 PM
post45557
Re: Killing shell on serial device   
On Wed, 2010-01-20 at 12:11 -0500, Tom Gogh wrote:
> Neil,
>      thanks for your quick reply!
> 
> But, I am not feeling comfortable to use slay assuming its implementation can be
> not efficient since if I am not terribly wrong, POSIX has no API that gives list of
> processes accessing the terminal or file so slay has to iterate over all PIDs and 
> check each of its tty matching the input tty.

(N.B. in the scenario I described you would be iterating over the
process names, rather than the controlling terminal, but the principle
is the same.)

You may want to consider whether this really needs to be a highly
optimized operation or not.  If so, then your system design should take
into account the need to track pids (along the lines you mention, either
by arranging to store the pid OOB or by parent-child relationship).  It
seems unlikely to me that this would be a performance critical
operation, but of course I don't know your specific application.  

Note that although POSIX doesn't define such an API, Neutrino specific
ones are available.  For example, you could write a program to search
the /proc filesystem and interpret the as files (which is essentially
what slay does anyway).  See the source for slay and for pidin to get a
feel for some of the mechanisms available.

You might also want to look into using HAM to monitor your processes.
You may be able to leverage it to do what you want.
Steve Reid
01/20/2010 12:58 PM
post45559
RE: Killing shell on serial device   
There's a section on the /proc filesystem in the Neutrino Programmer's
Guide:

 
http://www.qnx.com/developers/docs/6.4.1/neutrino/prog/process.html#proc
_filesystem


Steve Reid (stever@qnx.com)
Technical Editor
QNX Software Systems
Tom Gogh
01/21/2010 11:30 AM
post45664
Re: RE: Killing shell on serial device   
Steve,
      thanks for the link.
I have decided to go with spawn/exec model but it definitely  helped me to
understand how process model works
Tom Gogh
01/21/2010 11:29 AM
post45663
Re: Killing shell on serial device   
Neil,
     simple reason for choosing spawn/exec model is that my slay -t is not working 
and I am not sure putting time cycles to get it work is worth or not.
With spawn/exec model, it will be scalable for new design requirements.

I was not aware of slay, pidin source code is open in qnx code base given to users.
Though I couldn't find it in my view else I would have retrieved to modify esh code to log
its pid in IPC shared memory.
May I know where the source code is located?
Any links on qnx.com that can give idea which source code is open and/or where its located?
Neil Schellenberger(deleted)
01/21/2010 12:37 PM
post45673
RE: Killing shell on serial device   
I think perhaps I didn't make my original suggestion sufficiently clear.  I was suggesting using slay with only the 
process name as an argument, not the controlling terminal.  By arranging to have the shell which is running on the 
serial device have a unique name, you guarantee that you slay only exactly that process.

The source code for virtually the entire core operating system is available from the same place which is hosting this 
forum, Foundry 27.  If you look towards the top of the web page, you should see a bunch of "tabs", one of which is 
labelled "Source Code".  It's immediately to the left of "Discussions", which is the tab for the forums.

For you convenience, here's a directly link to slay:

http://community.qnx.com/integration/viewvc/viewvc.cgi/trunk/utils/s/slay/?root=coreos_pub&system=exsy1001

-----Original Message-----
From: Tom Gogh [mailto:community-noreply@qnx.com]
Sent: Thu 2010-01-21 11:29
To: ostech-core_os
Subject: Re: Killing shell on serial device
 
Neil,
     simple reason for choosing spawn/exec model is that my slay -t is not working 
and I am not sure putting time cycles to get it work is worth or not.
With spawn/exec model, it will be scalable for new design requirements.

I was not aware of slay, pidin source code is open in qnx code base given to users.
Though I couldn't find it in my view else I would have retrieved to modify esh code to log
its pid in IPC shared memory.
May I know where the source code is located?
Any links on qnx.com that can give idea which source code is open and/or where its located?




_______________________________________________

OSTech
http://community.qnx.com/sf/go/post45663
Tom Gogh
01/21/2010 12:51 PM
post45678
Re: RE: Killing shell on serial device   
Neil,
     esh is also running on other terminals, hence I can't just kill with slay all of them
but only one that runs on /dev/ser1.

Thanks for source code info, it will definitley resolve in many way for me to 
understand QNX for my application.
Tom Gogh
01/21/2010 12:55 PM
post45682
Re: RE: Killing shell on serial device   
Sorry to miss the one more point you made earlier to create a link for esh and 
run on /dev/ser1. Slay will kill process name as link name.
I think that will work out but I think as I suggested spawn/exec model will be more
scalable for me.
John Garvey
01/21/2010 1:41 PM
post45693
Re: Killing shell on serial device   
> One way I thought was to use slay command with -t option however, it's not 
> working out for me (always returns error that no process with esh name on /dev
> /ser1 tty)

Earlier versions of slay did indeed not support '-t'; current versions (post 2007) do appear to have implemented this 
functionality.  You didn't say which OS version (6.3.x or 6.4.x) you were using?

$ use -i slay
NAME=slay
DESCRIPTION=Kill or modify a process by name
DATE=2006/02/22-18:27:26-EST
STATE=Stable
HOST=compbuild
USER=oscomp
VERSION=6.3.2
TAGID=673

$ slay -q -t /dev/ttyp1 sh
slay: Unable to find process 'sh' on tty '/dev/ttyp1'

BUT now

$ slay -q -t /dev/ttyp1 sh
slay: bin/sh 1126443 on (tty not known) (y/N)? N

(The 'tty not known' seems to be an incomplete QNX4->6 port, and should be fixed).

So, if 'slay -t' is easier / was your first choice, then you could look to get a more recent 6.4 binary or build the 
latest from the posted source: [coreos_pub] / trunk / utils / s / slay).
Tom Gogh
01/22/2010 11:48 AM
post45784
Re: Killing shell on serial device   
John,
     thanks for reply.
I have 6.3.0 QNX. I am done with my spawn/exec design for esh kill, so, 
now I feel it's very scalable and I can use it as util process to get many
other things done in future.

John, Neil,
    I am checking licensing.qnx.com and I am not getting idea what part of
QNX source code is given out. As far as my code base is concerned, I have no
source code from QNX. By "virtually all operating system", do you mean
all QNX source code is available? Is it only 6.4.x onwards?

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems