Understanding Linux Processes with VAST

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Understanding Linux Processes with VAST

jtuchel
Hi,

I am in the process of understanding better how to find out which and how many VAST Seaside runtime images I have running on a (Linux based) Web Server and what I could do to start/stop some of them. This is important fur hot updates and stuff on a Web Server. I understand this will be a long learning process, but I need to start somewhere and understand little pieces one by one ;-)

So my current approach is very basic and my knowledge is very limited.

I usually do a
ps x | grep es

to see how many images I have running.

Interestingly, it seems starting one VM with an image shows 4 processes: the shell script that started an image and three instances of esnx.
Why do I see three esnx processes running? One of them has a status of "sl", the other two "s". What is each of them doing, why are there 3 processes at all? Am I using the wrong ps parameter?

When I issue a kill command, some of these three die immediately, one of them also drags another one to death whan it dies, and one of them always needs a kill -9. What does that mean?

This was the easy part.

Thinking into the future, I need a way to stop/update/restart one of several running images at a time (each of them listening onto another port) (I know there's gouing to be more to this, like telling apache not to dispatch to that image for a while and such). So the easiest and maybe lowest tech solution would be to kill the processes of only the image I want to update. One solution could be to write a file on image startup that contains the port number and the PID of the running process. This brings up a few questions:

* How do I find the current PID in my Smalltalk image?
* Can I find out all the PIDs of all three processes and store them in the file?
* Is there a way to kill a VM so that all processes die together? Which PID is the one I am looking for?

There sure are better ways to handle all this updating stuff and I remember seeing a blog post on how somebody solved the problem in Perl with Apache. So if anybody has some good suggestions, I'm happy to learn!

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/EkD_q0A-GMkJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: Understanding Linux Processes with VAST

John O'Keefe-3
Joachim -
 
When you start the first VA Smalltalk executable on Linux you will normally get 4 processes; starting additional VA Smalltalk executables normally adds 3 processes per executable. The processes are:
  • main process (the one running the image)
  • break button process
  • process server process (see UnixProcess>>#execProcess)
  • shared memory process
If you specify the -no_break command line parameter when starting the VA Smalltalk image, you should not get the break button process.
 
The shared memory process (there is only one) will hang around for a while (but not forever) even after the last VA Smalltalk executable is stopped. It does this so the shared memory bits (the stuff in /temp/es) doesn't have to be recreated if you decide to start a VA Smalltalk executable some time soon after shutting down the last VA Smalltalk executable. There is no real need to kill this process -- it will shutdown eventually (I don't remember the timeout value, but I can look it up if it is important).
 
The pid of the main process is written to the log file when the image is started -- not too convenient if you want to access it from the image. You can get the pid of the main process by adding a method (since I can't find any method in the image that sends this primitive):
 
EsSystemInfo class>>#pid
  "Answer the pid of the main process."
 
  <primitive: VMprSysInfoGetPid>
  ^ self primitiveFailed
 
The other 3 pids are not exposed to the image.
 
Killing the main process should kill all but the shared memory process.
 
I'll add this method into V8.5.2.
 
John
 

On Wednesday, June 27, 2012 8:08:07 AM UTC-4, [hidden email] wrote:

Hi,

I am in the process of understanding better how to find out which and how many VAST Seaside runtime images I have running on a (Linux based) Web Server and what I could do to start/stop some of them. This is important fur hot updates and stuff on a Web Server. I understand this will be a long learning process, but I need to start somewhere and understand little pieces one by one ;-)

So my current approach is very basic and my knowledge is very limited.

I usually do a
ps x | grep es

to see how many images I have running.

Interestingly, it seems starting one VM with an image shows 4 processes: the shell script that started an image and three instances of esnx.
Why do I see three esnx processes running? One of them has a status of "sl", the other two "s". What is each of them doing, why are there 3 processes at all? Am I using the wrong ps parameter?

When I issue a kill command, some of these three die immediately, one of them also drags another one to death whan it dies, and one of them always needs a kill -9. What does that mean?

This was the easy part.

Thinking into the future, I need a way to stop/update/restart one of several running images at a time (each of them listening onto another port) (I know there's gouing to be more to this, like telling apache not to dispatch to that image for a while and such). So the easiest and maybe lowest tech solution would be to kill the processes of only the image I want to update. One solution could be to write a file on image startup that contains the port number and the PID of the running process. This brings up a few questions:

* How do I find the current PID in my Smalltalk image?
* Can I find out all the PIDs of all three processes and store them in the file?
* Is there a way to kill a VM so that all processes die together? Which PID is the one I am looking for?

There sure are better ways to handle all this updating stuff and I remember seeing a blog post on how somebody solved the problem in Perl with Apache. So if anybody has some good suggestions, I'm happy to learn!

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/Os8uZGKt1tIJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: Understanding Linux Processes with VAST

Brad Selfridge
In reply to this post by jtuchel
Joachim,

I have run many instances of the same runtime image,  on AIX servers,
over the years. My solution was to create a separate file directory for
each instance that I wanted to run. I then gave each image a unique
name, (this way I could differentiate them from each other when I grep'd
them).  I wrote STOP, START, BOUNCE, STOPALL, STARTALL, and BOUNCEALL
shell scripts that allowed me to manage the starting and stopping of
images. One had to "cd" into each runtime directory to stop individual
image. But, the "ALL" scripts could be executed from any dirctory.

  Each running image opened a maintenance TCP port that allowed shell
scripts to send commands to it. When stopping an image, the "stop" shell
script would send a shutdown command, via the maintenance TCP port,  to
the running image. The shell script would then go into a wait loop,  for
several seconds, waiting for the image to shut itself down. If the image
didn't, then the shell script would execute a kill -9 on the image.

Since I located each runtime in a separate directory, I was able to
grep/awk for the PID inside my "stop" shell scripts.

To keep all of my runtime images in sync, I kept the original runtime
image in a parent "source" directory. When a "start" shell script was
executed, it automatically copied the "source" image down into the
"runtime" directory, re-named the original to the name stored in the
directory and then started the image.

--

Brad Selfridge
913-829-6980



On 6/27/2012 7:08 AM, [hidden email] wrote:

> Hi,
>
> I am in the process of understanding better how to find out which and
> how many VAST Seaside runtime images I have running on a (Linux based)
> Web Server and what I could do to start/stop some of them. This is
> important fur hot updates and stuff on a Web Server. I understand this
> will be a long learning process, but I need to start somewhere and
> understand little pieces one by one ;-)
>
> So my current approach is very basic and my knowledge is very limited.
>
> I usually do a
> ps x | grep es
>
> to see how many images I have running.
>
> Interestingly, it seems starting one VM with an image shows 4
> processes: the shell script that started an image and three instances
> of esnx.
> Why do I see three esnx processes running? One of them has a status of
> "sl", the other two "s". What is each of them doing, why are there 3
> processes at all? Am I using the wrong ps parameter?
>
> When I issue a kill command, some of these three die immediately, one
> of them also drags another one to death whan it dies, and one of them
> always needs a kill -9. What does that mean?
>
> This was the easy part.
>
> Thinking into the future, I need a way to stop/update/restart one of
> several running images at a time (each of them listening onto another
> port) (I know there's gouing to be more to this, like telling apache
> not to dispatch to that image for a while and such). So the easiest
> and maybe lowest tech solution would be to kill the processes of only
> the image I want to update. One solution could be to write a file on
> image startup that contains the port number and the PID of the running
> process. This brings up a few questions:
>
> * How do I find the current PID in my Smalltalk image?
> * Can I find out all the PIDs of all three processes and store them in
> the file?
> * Is there a way to kill a VM so that all processes die together?
> Which PID is the one I am looking for?
>
> There sure are better ways to handle all this updating stuff and I
> remember seeing a blog post on how somebody solved the problem in Perl
> with Apache. So if anybody has some good suggestions, I'm happy to learn!
>
> Joachim
> --
> You received this message because you are subscribed to the Google
> Groups "VA Smalltalk" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/va-smalltalk/-/EkD_q0A-GMkJ.
> To post to this group, send email to [hidden email].
> To unsubscribe from this group, send email to
> [hidden email].
> For more options, visit this group at
> http://groups.google.com/group/va-smalltalk?hl=en.



--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

Brad Selfridge
Reply | Threaded
Open this post in threaded view
|

Re: Understanding Linux Processes with VAST

Louis LaBrunda
In reply to this post by John O'Keefe-3
Hi Joachim and John,

I use this in windows:

pId := OSCall new getCurrentProcessId.

as OSCall is platform specific, it may contain a UNIX version of the code that works.

Lou


On Wednesday, June 27, 2012 10:04:42 AM UTC-4, John O'Keefe wrote:
Joachim -
 
When you start the first VA Smalltalk executable on Linux you will normally get 4 processes; starting additional VA Smalltalk executables normally adds 3 processes per executable. The processes are:
  • main process (the one running the image)
  • break button process
  • process server process (see UnixProcess>>#execProcess)
  • shared memory process
If you specify the -no_break command line parameter when starting the VA Smalltalk image, you should not get the break button process.
 
The shared memory process (there is only one) will hang around for a while (but not forever) even after the last VA Smalltalk executable is stopped. It does this so the shared memory bits (the stuff in /temp/es) doesn't have to be recreated if you decide to start a VA Smalltalk executable some time soon after shutting down the last VA Smalltalk executable. There is no real need to kill this process -- it will shutdown eventually (I don't remember the timeout value, but I can look it up if it is important).
 
The pid of the main process is written to the log file when the image is started -- not too convenient if you want to access it from the image. You can get the pid of the main process by adding a method (since I can't find any method in the image that sends this primitive):
 
EsSystemInfo class>>#pid
  "Answer the pid of the main process."
 
  <primitive: VMprSysInfoGetPid>
  ^ self primitiveFailed
 
The other 3 pids are not exposed to the image.
 
Killing the main process should kill all but the shared memory process.
 
I'll add this method into V8.5.2.
 
John
 

On Wednesday, June 27, 2012 8:08:07 AM UTC-4, [hidden email] wrote:

Hi,

I am in the process of understanding better how to find out which and how many VAST Seaside runtime images I have running on a (Linux based) Web Server and what I could do to start/stop some of them. This is important fur hot updates and stuff on a Web Server. I understand this will be a long learning process, but I need to start somewhere and understand little pieces one by one ;-)

So my current approach is very basic and my knowledge is very limited.

I usually do a
ps x | grep es

to see how many images I have running.

Interestingly, it seems starting one VM with an image shows 4 processes: the shell script that started an image and three instances of esnx.
Why do I see three esnx processes running? One of them has a status of "sl", the other two "s". What is each of them doing, why are there 3 processes at all? Am I using the wrong ps parameter?

When I issue a kill command, some of these three die immediately, one of them also drags another one to death whan it dies, and one of them always needs a kill -9. What does that mean?

This was the easy part.

Thinking into the future, I need a way to stop/update/restart one of several running images at a time (each of them listening onto another port) (I know there's gouing to be more to this, like telling apache not to dispatch to that image for a while and such). So the easiest and maybe lowest tech solution would be to kill the processes of only the image I want to update. One solution could be to write a file on image startup that contains the port number and the PID of the running process. This brings up a few questions:

* How do I find the current PID in my Smalltalk image?
* Can I find out all the PIDs of all three processes and store them in the file?
* Is there a way to kill a VM so that all processes die together? Which PID is the one I am looking for?

There sure are better ways to handle all this updating stuff and I remember seeing a blog post on how somebody solved the problem in Perl with Apache. So if anybody has some good suggestions, I'm happy to learn!

Joachim

On Wednesday, June 27, 2012 10:04:42 AM UTC-4, John O'Keefe wrote:
Joachim -
 
When you start the first VA Smalltalk executable on Linux you will normally get 4 processes; starting additional VA Smalltalk executables normally adds 3 processes per executable. The processes are:
  • main process (the one running the image)
  • break button process
  • process server process (see UnixProcess>>#execProcess)
  • shared memory process
If you specify the -no_break command line parameter when starting the VA Smalltalk image, you should not get the break button process.
 
The shared memory process (there is only one) will hang around for a while (but not forever) even after the last VA Smalltalk executable is stopped. It does this so the shared memory bits (the stuff in /temp/es) doesn't have to be recreated if you decide to start a VA Smalltalk executable some time soon after shutting down the last VA Smalltalk executable. There is no real need to kill this process -- it will shutdown eventually (I don't remember the timeout value, but I can look it up if it is important).
 
The pid of the main process is written to the log file when the image is started -- not too convenient if you want to access it from the image. You can get the pid of the main process by adding a method (since I can't find any method in the image that sends this primitive):
 
EsSystemInfo class>>#pid
  "Answer the pid of the main process."
 
  <primitive: VMprSysInfoGetPid>
  ^ self primitiveFailed
 
The other 3 pids are not exposed to the image.
 
Killing the main process should kill all but the shared memory process.
 
I'll add this method into V8.5.2.
 
John
 

On Wednesday, June 27, 2012 8:08:07 AM UTC-4, [hidden email] wrote:

Hi,

I am in the process of understanding better how to find out which and how many VAST Seaside runtime images I have running on a (Linux based) Web Server and what I could do to start/stop some of them. This is important fur hot updates and stuff on a Web Server. I understand this will be a long learning process, but I need to start somewhere and understand little pieces one by one ;-)

So my current approach is very basic and my knowledge is very limited.

I usually do a
ps x | grep es

to see how many images I have running.

Interestingly, it seems starting one VM with an image shows 4 processes: the shell script that started an image and three instances of esnx.
Why do I see three esnx processes running? One of them has a status of "sl", the other two "s". What is each of them doing, why are there 3 processes at all? Am I using the wrong ps parameter?

When I issue a kill command, some of these three die immediately, one of them also drags another one to death whan it dies, and one of them always needs a kill -9. What does that mean?

This was the easy part.

Thinking into the future, I need a way to stop/update/restart one of several running images at a time (each of them listening onto another port) (I know there's gouing to be more to this, like telling apache not to dispatch to that image for a while and such). So the easiest and maybe lowest tech solution would be to kill the processes of only the image I want to update. One solution could be to write a file on image startup that contains the port number and the PID of the running process. This brings up a few questions:

* How do I find the current PID in my Smalltalk image?
* Can I find out all the PIDs of all three processes and store them in the file?
* Is there a way to kill a VM so that all processes die together? Which PID is the one I am looking for?

There sure are better ways to handle all this updating stuff and I remember seeing a blog post on how somebody solved the problem in Perl with Apache. So if anybody has some good suggestions, I'm happy to learn!

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/WzBpP4RbpeIJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: Understanding Linux Processes with VAST

jtuchel
In reply to this post by John O'Keefe-3
John,

thanks a lot for this insightful description. Since I was using a packaged Image (did I mix es and esnx in my post?) there is no break button process, which explains my 3 processes.

the primitive sounds very useful - at least for my needs. So thanks again for posting it and adding it to 8.5.2. It's probably hidden in between your lines: killing that PID would kill all but the shared memory process. The shared memory process is probably the one that doesn't die with a simple kill, but needs a kill -9.

So all is set for more experimenting on the Unix system level ;-)

Joachim


Am Mittwoch, 27. Juni 2012 16:04:42 UTC+2 schrieb John O'Keefe:
Joachim -
 
When you start the first VA Smalltalk executable on Linux you will normally get 4 processes; starting additional VA Smalltalk executables normally adds 3 processes per executable. The processes are:
  • main process (the one running the image)
  • break button process
  • process server process (see UnixProcess>>#execProcess)
  • shared memory process
If you specify the -no_break command line parameter when starting the VA Smalltalk image, you should not get the break button process.
 
The shared memory process (there is only one) will hang around for a while (but not forever) even after the last VA Smalltalk executable is stopped. It does this so the shared memory bits (the stuff in /temp/es) doesn't have to be recreated if you decide to start a VA Smalltalk executable some time soon after shutting down the last VA Smalltalk executable. There is no real need to kill this process -- it will shutdown eventually (I don't remember the timeout value, but I can look it up if it is important).
 
The pid of the main process is written to the log file when the image is started -- not too convenient if you want to access it from the image. You can get the pid of the main process by adding a method (since I can't find any method in the image that sends this primitive):
 
EsSystemInfo class>>#pid
  "Answer the pid of the main process."
 
  <primitive: VMprSysInfoGetPid>
  ^ self primitiveFailed
 
The other 3 pids are not exposed to the image.
 
Killing the main process should kill all but the shared memory process.
 
I'll add this method into V8.5.2.
 
John
 

On Wednesday, June 27, 2012 8:08:07 AM UTC-4, [hidden email] wrote:

Hi,

I am in the process of understanding better how to find out which and how many VAST Seaside runtime images I have running on a (Linux based) Web Server and what I could do to start/stop some of them. This is important fur hot updates and stuff on a Web Server. I understand this will be a long learning process, but I need to start somewhere and understand little pieces one by one ;-)

So my current approach is very basic and my knowledge is very limited.

I usually do a
ps x | grep es

to see how many images I have running.

Interestingly, it seems starting one VM with an image shows 4 processes: the shell script that started an image and three instances of esnx.
Why do I see three esnx processes running? One of them has a status of "sl", the other two "s". What is each of them doing, why are there 3 processes at all? Am I using the wrong ps parameter?

When I issue a kill command, some of these three die immediately, one of them also drags another one to death whan it dies, and one of them always needs a kill -9. What does that mean?

This was the easy part.

Thinking into the future, I need a way to stop/update/restart one of several running images at a time (each of them listening onto another port) (I know there's gouing to be more to this, like telling apache not to dispatch to that image for a while and such). So the easiest and maybe lowest tech solution would be to kill the processes of only the image I want to update. One solution could be to write a file on image startup that contains the port number and the PID of the running process. This brings up a few questions:

* How do I find the current PID in my Smalltalk image?
* Can I find out all the PIDs of all three processes and store them in the file?
* Is there a way to kill a VM so that all processes die together? Which PID is the one I am looking for?

There sure are better ways to handle all this updating stuff and I remember seeing a blog post on how somebody solved the problem in Perl with Apache. So if anybody has some good suggestions, I'm happy to learn!

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/8pePc7rDDCcJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: Understanding Linux Processes with VAST

jtuchel
In reply to this post by Brad Selfridge

Hi Brad,

the solution you describe is so pragmatic and perfectly understandable. I like the clarity based on the directory the application was started from. I think I'll experiment a bit with this and see how I could use it to also tell Apache to take the respective Image out of its load balancing scheme for a while...

I'm glad I asked this question here.

Joachim

Am Mittwoch, 27. Juni 2012 16:20:39 UTC+2 schrieb Brad Selfridge:
Joachim,

I have run many instances of the same runtime image,  on AIX servers,
over the years. My solution was to create a separate file directory for
each instance that I wanted to run. I then gave each image a unique
name, (this way I could differentiate them from each other when I grep'd
them).  I wrote STOP, START, BOUNCE, STOPALL, STARTALL, and BOUNCEALL
shell scripts that allowed me to manage the starting and stopping of
images. One had to "cd" into each runtime directory to stop individual
image. But, the "ALL" scripts could be executed from any dirctory.

  Each running image opened a maintenance TCP port that allowed shell
scripts to send commands to it. When stopping an image, the "stop" shell
script would send a shutdown command, via the maintenance TCP port,  to
the running image. The shell script would then go into a wait loop,  for
several seconds, waiting for the image to shut itself down. If the image
didn't, then the shell script would execute a kill -9 on the image.

Since I located each runtime in a separate directory, I was able to
grep/awk for the PID inside my "stop" shell scripts.

To keep all of my runtime images in sync, I kept the original runtime
image in a parent "source" directory. When a "start" shell script was
executed, it automatically copied the "source" image down into the
"runtime" directory, re-named the original to the name stored in the
directory and then started the image.

--

Brad Selfridge
913-829-6980



On 6/27/2012 7:08 AM, jtuchel@o..brik.de wrote:

> Hi,
>
> I am in the process of understanding better how to find out which and
> how many VAST Seaside runtime images I have running on a (Linux based)
> Web Server and what I could do to start/stop some of them. This is
> important fur hot updates and stuff on a Web Server. I understand this
> will be a long learning process, but I need to start somewhere and
> understand little pieces one by one ;-)
>
> So my current approach is very basic and my knowledge is very limited.
>
> I usually do a
> ps x | grep es
>
> to see how many images I have running.
>
> Interestingly, it seems starting one VM with an image shows 4
> processes: the shell script that started an image and three instances
> of esnx.
> Why do I see three esnx processes running? One of them has a status of
> "sl", the other two "s". What is each of them doing, why are there 3
> processes at all? Am I using the wrong ps parameter?
>
> When I issue a kill command, some of these three die immediately, one
> of them also drags another one to death whan it dies, and one of them
> always needs a kill -9. What does that mean?
>
> This was the easy part.
>
> Thinking into the future, I need a way to stop/update/restart one of
> several running images at a time (each of them listening onto another
> port) (I know there's gouing to be more to this, like telling apache
> not to dispatch to that image for a while and such). So the easiest
> and maybe lowest tech solution would be to kill the processes of only
> the image I want to update. One solution could be to write a file on
> image startup that contains the port number and the PID of the running
> process. This brings up a few questions:
>
> * How do I find the current PID in my Smalltalk image?
> * Can I find out all the PIDs of all three processes and store them in
> the file?
> * Is there a way to kill a VM so that all processes die together?
> Which PID is the one I am looking for?
>
> There sure are better ways to handle all this updating stuff and I
> remember seeing a blog post on how somebody solved the problem in Perl
> with Apache. So if anybody has some good suggestions, I'm happy to learn!
>
> Joachim
> --




--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/ahKStJ74laYJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: Understanding Linux Processes with VAST

jtuchel
In reply to this post by Louis LaBrunda
Thanks Lou,

I'll see if it's available on Linux, but I guess it isn't, based on John's answer.

Joachim

Am Mittwoch, 27. Juni 2012 16:27:17 UTC+2 schrieb Louis LaBrunda:
Hi Joachim and John,

I use this in windows:

pId := OSCall new getCurrentProcessId.

as OSCall is platform specific, it may contain a UNIX version of the code that works.

Lou


On Wednesday, June 27, 2012 10:04:42 AM UTC-4, John O'Keefe wrote:
Joachim -
 
When you start the first VA Smalltalk executable on Linux you will normally get 4 processes; starting additional VA Smalltalk executables normally adds 3 processes per executable. The processes are:
  • main process (the one running the image)
  • break button process
  • process server process (see UnixProcess>>#execProcess)
  • shared memory process
If you specify the -no_break command line parameter when starting the VA Smalltalk image, you should not get the break button process.
 
The shared memory process (there is only one) will hang around for a while (but not forever) even after the last VA Smalltalk executable is stopped. It does this so the shared memory bits (the stuff in /temp/es) doesn't have to be recreated if you decide to start a VA Smalltalk executable some time soon after shutting down the last VA Smalltalk executable. There is no real need to kill this process -- it will shutdown eventually (I don't remember the timeout value, but I can look it up if it is important).
 
The pid of the main process is written to the log file when the image is started -- not too convenient if you want to access it from the image. You can get the pid of the main process by adding a method (since I can't find any method in the image that sends this primitive):
 
EsSystemInfo class>>#pid
  "Answer the pid of the main process."
 
  <primitive: VMprSysInfoGetPid>
  ^ self primitiveFailed
 
The other 3 pids are not exposed to the image.
 
Killing the main process should kill all but the shared memory process.
 
I'll add this method into V8.5.2.
 
John
 

On Wednesday, June 27, 2012 8:08:07 AM UTC-4, [hidden email] wrote:

Hi,

I am in the process of understanding better how to find out which and how many VAST Seaside runtime images I have running on a (Linux based) Web Server and what I could do to start/stop some of them. This is important fur hot updates and stuff on a Web Server. I understand this will be a long learning process, but I need to start somewhere and understand little pieces one by one ;-)

So my current approach is very basic and my knowledge is very limited.

I usually do a
ps x | grep es

to see how many images I have running.

Interestingly, it seems starting one VM with an image shows 4 processes: the shell script that started an image and three instances of esnx.
Why do I see three esnx processes running? One of them has a status of "sl", the other two "s". What is each of them doing, why are there 3 processes at all? Am I using the wrong ps parameter?

When I issue a kill command, some of these three die immediately, one of them also drags another one to death whan it dies, and one of them always needs a kill -9. What does that mean?

This was the easy part.

Thinking into the future, I need a way to stop/update/restart one of several running images at a time (each of them listening onto another port) (I know there's gouing to be more to this, like telling apache not to dispatch to that image for a while and such). So the easiest and maybe lowest tech solution would be to kill the processes of only the image I want to update. One solution could be to write a file on image startup that contains the port number and the PID of the running process. This brings up a few questions:

* How do I find the current PID in my Smalltalk image?
* Can I find out all the PIDs of all three processes and store them in the file?
* Is there a way to kill a VM so that all processes die together? Which PID is the one I am looking for?

There sure are better ways to handle all this updating stuff and I remember seeing a blog post on how somebody solved the problem in Perl with Apache. So if anybody has some good suggestions, I'm happy to learn!

Joachim

On Wednesday, June 27, 2012 10:04:42 AM UTC-4, John O'Keefe wrote:
Joachim -
 
When you start the first VA Smalltalk executable on Linux you will normally get 4 processes; starting additional VA Smalltalk executables normally adds 3 processes per executable. The processes are:
  • main process (the one running the image)
  • break button process
  • process server process (see UnixProcess>>#execProcess)
  • shared memory process
If you specify the -no_break command line parameter when starting the VA Smalltalk image, you should not get the break button process.
 
The shared memory process (there is only one) will hang around for a while (but not forever) even after the last VA Smalltalk executable is stopped. It does this so the shared memory bits (the stuff in /temp/es) doesn't have to be recreated if you decide to start a VA Smalltalk executable some time soon after shutting down the last VA Smalltalk executable. There is no real need to kill this process -- it will shutdown eventually (I don't remember the timeout value, but I can look it up if it is important).
 
The pid of the main process is written to the log file when the image is started -- not too convenient if you want to access it from the image. You can get the pid of the main process by adding a method (since I can't find any method in the image that sends this primitive):
 
EsSystemInfo class>>#pid
  "Answer the pid of the main process."
 
  <primitive: VMprSysInfoGetPid>
  ^ self primitiveFailed
 
The other 3 pids are not exposed to the image.
 
Killing the main process should kill all but the shared memory process.
 
I'll add this method into V8.5.2.
 
John
 

On Wednesday, June 27, 2012 8:08:07 AM UTC-4, [hidden email] wrote:

Hi,

I am in the process of understanding better how to find out which and how many VAST Seaside runtime images I have running on a (Linux based) Web Server and what I could do to start/stop some of them. This is important fur hot updates and stuff on a Web Server. I understand this will be a long learning process, but I need to start somewhere and understand little pieces one by one ;-)

So my current approach is very basic and my knowledge is very limited.

I usually do a
ps x | grep es

to see how many images I have running.

Interestingly, it seems starting one VM with an image shows 4 processes: the shell script that started an image and three instances of esnx.
Why do I see three esnx processes running? One of them has a status of "sl", the other two "s". What is each of them doing, why are there 3 processes at all? Am I using the wrong ps parameter?

When I issue a kill command, some of these three die immediately, one of them also drags another one to death whan it dies, and one of them always needs a kill -9. What does that mean?

This was the easy part.

Thinking into the future, I need a way to stop/update/restart one of several running images at a time (each of them listening onto another port) (I know there's gouing to be more to this, like telling apache not to dispatch to that image for a while and such). So the easiest and maybe lowest tech solution would be to kill the processes of only the image I want to update. One solution could be to write a file on image startup that contains the port number and the PID of the running process. This brings up a few questions:

* How do I find the current PID in my Smalltalk image?
* Can I find out all the PIDs of all three processes and store them in the file?
* Is there a way to kill a VM so that all processes die together? Which PID is the one I am looking for?

There sure are better ways to handle all this updating stuff and I remember seeing a blog post on how somebody solved the problem in Perl with Apache. So if anybody has some good suggestions, I'm happy to learn!

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/LooRmhros4wJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: Understanding Linux Processes with VAST

John O'Keefe-3
In reply to this post by Louis LaBrunda
Lou and Joachim -
 
There is no equivalent call implemented in the Unix image. Using the method I provided is platform-independent - it does GetCurrentProcessID() (Windows) or getpid() (Unix).
 
John
 

On Wednesday, June 27, 2012 10:27:17 AM UTC-4, Louis LaBrunda wrote:
Hi Joachim and John,

I use this in windows:

pId := OSCall new getCurrentProcessId.

as OSCall is platform specific, it may contain a UNIX version of the code that works.

Lou


On Wednesday, June 27, 2012 10:04:42 AM UTC-4, John O'Keefe wrote:
Joachim -
 
When you start the first VA Smalltalk executable on Linux you will normally get 4 processes; starting additional VA Smalltalk executables normally adds 3 processes per executable. The processes are:
  • main process (the one running the image)
  • break button process
  • process server process (see UnixProcess>>#execProcess)
  • shared memory process
If you specify the -no_break command line parameter when starting the VA Smalltalk image, you should not get the break button process.
 
The shared memory process (there is only one) will hang around for a while (but not forever) even after the last VA Smalltalk executable is stopped. It does this so the shared memory bits (the stuff in /temp/es) doesn't have to be recreated if you decide to start a VA Smalltalk executable some time soon after shutting down the last VA Smalltalk executable. There is no real need to kill this process -- it will shutdown eventually (I don't remember the timeout value, but I can look it up if it is important).
 
The pid of the main process is written to the log file when the image is started -- not too convenient if you want to access it from the image. You can get the pid of the main process by adding a method (since I can't find any method in the image that sends this primitive):
 
EsSystemInfo class>>#pid
  "Answer the pid of the main process."
 
  <primitive: VMprSysInfoGetPid>
  ^ self primitiveFailed
 
The other 3 pids are not exposed to the image.
 
Killing the main process should kill all but the shared memory process.
 
I'll add this method into V8.5.2.
 
John
 

On Wednesday, June 27, 2012 8:08:07 AM UTC-4, [hidden email] wrote:

Hi,

I am in the process of understanding better how to find out which and how many VAST Seaside runtime images I have running on a (Linux based) Web Server and what I could do to start/stop some of them. This is important fur hot updates and stuff on a Web Server. I understand this will be a long learning process, but I need to start somewhere and understand little pieces one by one ;-)

So my current approach is very basic and my knowledge is very limited.

I usually do a
ps x | grep es

to see how many images I have running.

Interestingly, it seems starting one VM with an image shows 4 processes: the shell script that started an image and three instances of esnx.
Why do I see three esnx processes running? One of them has a status of "sl", the other two "s". What is each of them doing, why are there 3 processes at all? Am I using the wrong ps parameter?

When I issue a kill command, some of these three die immediately, one of them also drags another one to death whan it dies, and one of them always needs a kill -9. What does that mean?

This was the easy part.

Thinking into the future, I need a way to stop/update/restart one of several running images at a time (each of them listening onto another port) (I know there's gouing to be more to this, like telling apache not to dispatch to that image for a while and such). So the easiest and maybe lowest tech solution would be to kill the processes of only the image I want to update. One solution could be to write a file on image startup that contains the port number and the PID of the running process. This brings up a few questions:

* How do I find the current PID in my Smalltalk image?
* Can I find out all the PIDs of all three processes and store them in the file?
* Is there a way to kill a VM so that all processes die together? Which PID is the one I am looking for?

There sure are better ways to handle all this updating stuff and I remember seeing a blog post on how somebody solved the problem in Perl with Apache. So if anybody has some good suggestions, I'm happy to learn!

Joachim

On Wednesday, June 27, 2012 10:04:42 AM UTC-4, John O'Keefe wrote:
Joachim -
 
When you start the first VA Smalltalk executable on Linux you will normally get 4 processes; starting additional VA Smalltalk executables normally adds 3 processes per executable. The processes are:
  • main process (the one running the image)
  • break button process
  • process server process (see UnixProcess>>#execProcess)
  • shared memory process
If you specify the -no_break command line parameter when starting the VA Smalltalk image, you should not get the break button process.
 
The shared memory process (there is only one) will hang around for a while (but not forever) even after the last VA Smalltalk executable is stopped. It does this so the shared memory bits (the stuff in /temp/es) doesn't have to be recreated if you decide to start a VA Smalltalk executable some time soon after shutting down the last VA Smalltalk executable. There is no real need to kill this process -- it will shutdown eventually (I don't remember the timeout value, but I can look it up if it is important).
 
The pid of the main process is written to the log file when the image is started -- not too convenient if you want to access it from the image. You can get the pid of the main process by adding a method (since I can't find any method in the image that sends this primitive):
 
EsSystemInfo class>>#pid
  "Answer the pid of the main process."
 
  <primitive: VMprSysInfoGetPid>
  ^ self primitiveFailed
 
The other 3 pids are not exposed to the image.
 
Killing the main process should kill all but the shared memory process.
 
I'll add this method into V8.5.2.
 
John
 

On Wednesday, June 27, 2012 8:08:07 AM UTC-4, [hidden email] wrote:

Hi,

I am in the process of understanding better how to find out which and how many VAST Seaside runtime images I have running on a (Linux based) Web Server and what I could do to start/stop some of them. This is important fur hot updates and stuff on a Web Server. I understand this will be a long learning process, but I need to start somewhere and understand little pieces one by one ;-)

So my current approach is very basic and my knowledge is very limited.

I usually do a
ps x | grep es

to see how many images I have running.

Interestingly, it seems starting one VM with an image shows 4 processes: the shell script that started an image and three instances of esnx.
Why do I see three esnx processes running? One of them has a status of "sl", the other two "s". What is each of them doing, why are there 3 processes at all? Am I using the wrong ps parameter?

When I issue a kill command, some of these three die immediately, one of them also drags another one to death whan it dies, and one of them always needs a kill -9. What does that mean?

This was the easy part.

Thinking into the future, I need a way to stop/update/restart one of several running images at a time (each of them listening onto another port) (I know there's gouing to be more to this, like telling apache not to dispatch to that image for a while and such). So the easiest and maybe lowest tech solution would be to kill the processes of only the image I want to update. One solution could be to write a file on image startup that contains the port number and the PID of the running process. This brings up a few questions:

* How do I find the current PID in my Smalltalk image?
* Can I find out all the PIDs of all three processes and store them in the file?
* Is there a way to kill a VM so that all processes die together? Which PID is the one I am looking for?

There sure are better ways to handle all this updating stuff and I remember seeing a blog post on how somebody solved the problem in Perl with Apache. So if anybody has some good suggestions, I'm happy to learn!

Joachim

On Wednesday, June 27, 2012 10:27:17 AM UTC-4, Louis LaBrunda wrote:
Hi Joachim and John,

I use this in windows:

pId := OSCall new getCurrentProcessId.

as OSCall is platform specific, it may contain a UNIX version of the code that works.

Lou


On Wednesday, June 27, 2012 10:04:42 AM UTC-4, John O'Keefe wrote:
Joachim -
 
When you start the first VA Smalltalk executable on Linux you will normally get 4 processes; starting additional VA Smalltalk executables normally adds 3 processes per executable. The processes are:
  • main process (the one running the image)
  • break button process
  • process server process (see UnixProcess>>#execProcess)
  • shared memory process
If you specify the -no_break command line parameter when starting the VA Smalltalk image, you should not get the break button process.
 
The shared memory process (there is only one) will hang around for a while (but not forever) even after the last VA Smalltalk executable is stopped. It does this so the shared memory bits (the stuff in /temp/es) doesn't have to be recreated if you decide to start a VA Smalltalk executable some time soon after shutting down the last VA Smalltalk executable. There is no real need to kill this process -- it will shutdown eventually (I don't remember the timeout value, but I can look it up if it is important).
 
The pid of the main process is written to the log file when the image is started -- not too convenient if you want to access it from the image. You can get the pid of the main process by adding a method (since I can't find any method in the image that sends this primitive):
 
EsSystemInfo class>>#pid
  "Answer the pid of the main process."
 
  <primitive: VMprSysInfoGetPid>
  ^ self primitiveFailed
 
The other 3 pids are not exposed to the image.
 
Killing the main process should kill all but the shared memory process.
 
I'll add this method into V8.5.2.
 
John
 

On Wednesday, June 27, 2012 8:08:07 AM UTC-4, [hidden email] wrote:

Hi,

I am in the process of understanding better how to find out which and how many VAST Seaside runtime images I have running on a (Linux based) Web Server and what I could do to start/stop some of them. This is important fur hot updates and stuff on a Web Server. I understand this will be a long learning process, but I need to start somewhere and understand little pieces one by one ;-)

So my current approach is very basic and my knowledge is very limited.

I usually do a
ps x | grep es

to see how many images I have running.

Interestingly, it seems starting one VM with an image shows 4 processes: the shell script that started an image and three instances of esnx.
Why do I see three esnx processes running? One of them has a status of "sl", the other two "s". What is each of them doing, why are there 3 processes at all? Am I using the wrong ps parameter?

When I issue a kill command, some of these three die immediately, one of them also drags another one to death whan it dies, and one of them always needs a kill -9. What does that mean?

This was the easy part.

Thinking into the future, I need a way to stop/update/restart one of several running images at a time (each of them listening onto another port) (I know there's gouing to be more to this, like telling apache not to dispatch to that image for a while and such). So the easiest and maybe lowest tech solution would be to kill the processes of only the image I want to update. One solution could be to write a file on image startup that contains the port number and the PID of the running process. This brings up a few questions:

* How do I find the current PID in my Smalltalk image?
* Can I find out all the PIDs of all three processes and store them in the file?
* Is there a way to kill a VM so that all processes die together? Which PID is the one I am looking for?

There sure are better ways to handle all this updating stuff and I remember seeing a blog post on how somebody solved the problem in Perl with Apache. So if anybody has some good suggestions, I'm happy to learn!

Joachim

On Wednesday, June 27, 2012 10:04:42 AM UTC-4, John O'Keefe wrote:
Joachim -
 
When you start the first VA Smalltalk executable on Linux you will normally get 4 processes; starting additional VA Smalltalk executables normally adds 3 processes per executable. The processes are:
  • main process (the one running the image)
  • break button process
  • process server process (see UnixProcess>>#execProcess)
  • shared memory process
If you specify the -no_break command line parameter when starting the VA Smalltalk image, you should not get the break button process.
 
The shared memory process (there is only one) will hang around for a while (but not forever) even after the last VA Smalltalk executable is stopped. It does this so the shared memory bits (the stuff in /temp/es) doesn't have to be recreated if you decide to start a VA Smalltalk executable some time soon after shutting down the last VA Smalltalk executable. There is no real need to kill this process -- it will shutdown eventually (I don't remember the timeout value, but I can look it up if it is important).
 
The pid of the main process is written to the log file when the image is started -- not too convenient if you want to access it from the image. You can get the pid of the main process by adding a method (since I can't find any method in the image that sends this primitive):
 
EsSystemInfo class>>#pid
  "Answer the pid of the main process."
 
  <primitive: VMprSysInfoGetPid>
  ^ self primitiveFailed
 
The other 3 pids are not exposed to the image.
 
Killing the main process should kill all but the shared memory process.
 
I'll add this method into V8.5.2.
 
John
 

On Wednesday, June 27, 2012 8:08:07 AM UTC-4, [hidden email] wrote:

Hi,

I am in the process of understanding better how to find out which and how many VAST Seaside runtime images I have running on a (Linux based) Web Server and what I could do to start/stop some of them. This is important fur hot updates and stuff on a Web Server. I understand this will be a long learning process, but I need to start somewhere and understand little pieces one by one ;-)

So my current approach is very basic and my knowledge is very limited.

I usually do a
ps x | grep es

to see how many images I have running.

Interestingly, it seems starting one VM with an image shows 4 processes: the shell script that started an image and three instances of esnx.
Why do I see three esnx processes running? One of them has a status of "sl", the other two "s". What is each of them doing, why are there 3 processes at all? Am I using the wrong ps parameter?

When I issue a kill command, some of these three die immediately, one of them also drags another one to death whan it dies, and one of them always needs a kill -9. What does that mean?

This was the easy part.

Thinking into the future, I need a way to stop/update/restart one of several running images at a time (each of them listening onto another port) (I know there's gouing to be more to this, like telling apache not to dispatch to that image for a while and such). So the easiest and maybe lowest tech solution would be to kill the processes of only the image I want to update. One solution could be to write a file on image startup that contains the port number and the PID of the running process. This brings up a few questions:

* How do I find the current PID in my Smalltalk image?
* Can I find out all the PIDs of all three processes and store them in the file?
* Is there a way to kill a VM so that all processes die together? Which PID is the one I am looking for?

There sure are better ways to handle all this updating stuff and I remember seeing a blog post on how somebody solved the problem in Perl with Apache. So if anybody has some good suggestions, I'm happy to learn!

Joachim

On Wednesday, June 27, 2012 10:27:17 AM UTC-4, Louis LaBrunda wrote:
Hi Joachim and John,

I use this in windows:

pId := OSCall new getCurrentProcessId.

as OSCall is platform specific, it may contain a UNIX version of the code that works.

Lou


On Wednesday, June 27, 2012 10:04:42 AM UTC-4, John O'Keefe wrote:
Joachim -
 
When you start the first VA Smalltalk executable on Linux you will normally get 4 processes; starting additional VA Smalltalk executables normally adds 3 processes per executable. The processes are:
  • main process (the one running the image)
  • break button process
  • process server process (see UnixProcess>>#execProcess)
  • shared memory process
If you specify the -no_break command line parameter when starting the VA Smalltalk image, you should not get the break button process.
 
The shared memory process (there is only one) will hang around for a while (but not forever) even after the last VA Smalltalk executable is stopped. It does this so the shared memory bits (the stuff in /temp/es) doesn't have to be recreated if you decide to start a VA Smalltalk executable some time soon after shutting down the last VA Smalltalk executable. There is no real need to kill this process -- it will shutdown eventually (I don't remember the timeout value, but I can look it up if it is important).
 
The pid of the main process is written to the log file when the image is started -- not too convenient if you want to access it from the image. You can get the pid of the main process by adding a method (since I can't find any method in the image that sends this primitive):
 
EsSystemInfo class>>#pid
  "Answer the pid of the main process."
 
  <primitive: VMprSysInfoGetPid>
  ^ self primitiveFailed
 
The other 3 pids are not exposed to the image.
 
Killing the main process should kill all but the shared memory process.
 
I'll add this method into V8.5.2.
 
John
 

On Wednesday, June 27, 2012 8:08:07 AM UTC-4, [hidden email] wrote:

Hi,

I am in the process of understanding better how to find out which and how many VAST Seaside runtime images I have running on a (Linux based) Web Server and what I could do to start/stop some of them. This is important fur hot updates and stuff on a Web Server. I understand this will be a long learning process, but I need to start somewhere and understand little pieces one by one ;-)

So my current approach is very basic and my knowledge is very limited.

I usually do a
ps x | grep es

to see how many images I have running.

Interestingly, it seems starting one VM with an image shows 4 processes: the shell script that started an image and three instances of esnx.
Why do I see three esnx processes running? One of them has a status of "sl", the other two "s". What is each of them doing, why are there 3 processes at all? Am I using the wrong ps parameter?

When I issue a kill command, some of these three die immediately, one of them also drags another one to death whan it dies, and one of them always needs a kill -9. What does that mean?

This was the easy part.

Thinking into the future, I need a way to stop/update/restart one of several running images at a time (each of them listening onto another port) (I know there's gouing to be more to this, like telling apache not to dispatch to that image for a while and such). So the easiest and maybe lowest tech solution would be to kill the processes of only the image I want to update. One solution could be to write a file on image startup that contains the port number and the PID of the running process. This brings up a few questions:

* How do I find the current PID in my Smalltalk image?
* Can I find out all the PIDs of all three processes and store them in the file?
* Is there a way to kill a VM so that all processes die together? Which PID is the one I am looking for?

There sure are better ways to handle all this updating stuff and I remember seeing a blog post on how somebody solved the problem in Perl with Apache. So if anybody has some good suggestions, I'm happy to learn!

Joachim

On Wednesday, June 27, 2012 10:04:42 AM UTC-4, John O'Keefe wrote:
Joachim -
 
When you start the first VA Smalltalk executable on Linux you will normally get 4 processes; starting additional VA Smalltalk executables normally adds 3 processes per executable. The processes are:
  • main process (the one running the image)
  • break button process
  • process server process (see UnixProcess>>#execProcess)
  • shared memory process
If you specify the -no_break command line parameter when starting the VA Smalltalk image, you should not get the break button process.
 
The shared memory process (there is only one) will hang around for a while (but not forever) even after the last VA Smalltalk executable is stopped. It does this so the shared memory bits (the stuff in /temp/es) doesn't have to be recreated if you decide to start a VA Smalltalk executable some time soon after shutting down the last VA Smalltalk executable. There is no real need to kill this process -- it will shutdown eventually (I don't remember the timeout value, but I can look it up if it is important).
 
The pid of the main process is written to the log file when the image is started -- not too convenient if you want to access it from the image. You can get the pid of the main process by adding a method (since I can't find any method in the image that sends this primitive):
 
EsSystemInfo class>>#pid
  "Answer the pid of the main process."
 
  <primitive: VMprSysInfoGetPid>
  ^ self primitiveFailed
 
The other 3 pids are not exposed to the image.
 
Killing the main process should kill all but the shared memory process.
 
I'll add this method into V8.5.2.
 
John
 

On Wednesday, June 27, 2012 8:08:07 AM UTC-4, [hidden email] wrote:

Hi,

I am in the process of understanding better how to find out which and how many VAST Seaside runtime images I have running on a (Linux based) Web Server and what I could do to start/stop some of them. This is important fur hot updates and stuff on a Web Server. I understand this will be a long learning process, but I need to start somewhere and understand little pieces one by one ;-)

So my current approach is very basic and my knowledge is very limited.

I usually do a
ps x | grep es

to see how many images I have running.

Interestingly, it seems starting one VM with an image shows 4 processes: the shell script that started an image and three instances of esnx.
Why do I see three esnx processes running? One of them has a status of "sl", the other two "s". What is each of them doing, why are there 3 processes at all? Am I using the wrong ps parameter?

When I issue a kill command, some of these three die immediately, one of them also drags another one to death whan it dies, and one of them always needs a kill -9. What does that mean?

This was the easy part.

Thinking into the future, I need a way to stop/update/restart one of several running images at a time (each of them listening onto another port) (I know there's gouing to be more to this, like telling apache not to dispatch to that image for a while and such). So the easiest and maybe lowest tech solution would be to kill the processes of only the image I want to update. One solution could be to write a file on image startup that contains the port number and the PID of the running process. This brings up a few questions:

* How do I find the current PID in my Smalltalk image?
* Can I find out all the PIDs of all three processes and store them in the file?
* Is there a way to kill a VM so that all processes die together? Which PID is the one I am looking for?

There sure are better ways to handle all this updating stuff and I remember seeing a blog post on how somebody solved the problem in Perl with Apache. So if anybody has some good suggestions, I'm happy to learn!

Joachim

On Wednesday, June 27, 2012 10:27:17 AM UTC-4, Louis LaBrunda wrote:
Hi Joachim and John,

I use this in windows:

pId := OSCall new getCurrentProcessId.

as OSCall is platform specific, it may contain a UNIX version of the code that works.

Lou


On Wednesday, June 27, 2012 10:04:42 AM UTC-4, John O'Keefe wrote:
Joachim -
 
When you start the first VA Smalltalk executable on Linux you will normally get 4 processes; starting additional VA Smalltalk executables normally adds 3 processes per executable. The processes are:
  • main process (the one running the image)
  • break button process
  • process server process (see UnixProcess>>#execProcess)
  • shared memory process
If you specify the -no_break command line parameter when starting the VA Smalltalk image, you should not get the break button process.
 
The shared memory process (there is only one) will hang around for a while (but not forever) even after the last VA Smalltalk executable is stopped. It does this so the shared memory bits (the stuff in /temp/es) doesn't have to be recreated if you decide to start a VA Smalltalk executable some time soon after shutting down the last VA Smalltalk executable. There is no real need to kill this process -- it will shutdown eventually (I don't remember the timeout value, but I can look it up if it is important).
 
The pid of the main process is written to the log file when the image is started -- not too convenient if you want to access it from the image. You can get the pid of the main process by adding a method (since I can't find any method in the image that sends this primitive):
 
EsSystemInfo class>>#pid
  "Answer the pid of the main process."
 
  <primitive: VMprSysInfoGetPid>
  ^ self primitiveFailed
 
The other 3 pids are not exposed to the image.
 
Killing the main process should kill all but the shared memory process.
 
I'll add this method into V8.5.2.
 
John
 

On Wednesday, June 27, 2012 8:08:07 AM UTC-4, [hidden email] wrote:

Hi,

I am in the process of understanding better how to find out which and how many VAST Seaside runtime images I have running on a (Linux based) Web Server and what I could do to start/stop some of them. This is important fur hot updates and stuff on a Web Server. I understand this will be a long learning process, but I need to start somewhere and understand little pieces one by one ;-)

So my current approach is very basic and my knowledge is very limited.

I usually do a
ps x | grep es

to see how many images I have running.

Interestingly, it seems starting one VM with an image shows 4 processes: the shell script that started an image and three instances of esnx.
Why do I see three esnx processes running? One of them has a status of "sl", the other two "s". What is each of them doing, why are there 3 processes at all? Am I using the wrong ps parameter?

When I issue a kill command, some of these three die immediately, one of them also drags another one to death whan it dies, and one of them always needs a kill -9. What does that mean?

This was the easy part.

Thinking into the future, I need a way to stop/update/restart one of several running images at a time (each of them listening onto another port) (I know there's gouing to be more to this, like telling apache not to dispatch to that image for a while and such). So the easiest and maybe lowest tech solution would be to kill the processes of only the image I want to update. One solution could be to write a file on image startup that contains the port number and the PID of the running process. This brings up a few questions:

* How do I find the current PID in my Smalltalk image?
* Can I find out all the PIDs of all three processes and store them in the file?
* Is there a way to kill a VM so that all processes die together? Which PID is the one I am looking for?

There sure are better ways to handle all this updating stuff and I remember seeing a blog post on how somebody solved the problem in Perl with Apache. So if anybody has some good suggestions, I'm happy to learn!

Joachim

On Wednesday, June 27, 2012 10:04:42 AM UTC-4, John O'Keefe wrote:
Joachim -
 
When you start the first VA Smalltalk executable on Linux you will normally get 4 processes; starting additional VA Smalltalk executables normally adds 3 processes per executable. The processes are:
  • main process (the one running the image)
  • break button process
  • process server process (see UnixProcess>>#execProcess)
  • shared memory process
If you specify the -no_break command line parameter when starting the VA Smalltalk image, you should not get the break button process.
 
The shared memory process (there is only one) will hang around for a while (but not forever) even after the last VA Smalltalk executable is stopped. It does this so the shared memory bits (the stuff in /temp/es) doesn't have to be recreated if you decide to start a VA Smalltalk executable some time soon after shutting down the last VA Smalltalk executable. There is no real need to kill this process -- it will shutdown eventually (I don't remember the timeout value, but I can look it up if it is important).
 
The pid of the main process is written to the log file when the image is started -- not too convenient if you want to access it from the image. You can get the pid of the main process by adding a method (since I can't find any method in the image that sends this primitive):
 
EsSystemInfo class>>#pid
  "Answer the pid of the main process."
 
  <primitive: VMprSysInfoGetPid>
  ^ self primitiveFailed
 
The other 3 pids are not exposed to the image.
 
Killing the main process should kill all but the shared memory process.
 
I'll add this method into V8.5.2.
 
John
 

On Wednesday, June 27, 2012 8:08:07 AM UTC-4, [hidden email] wrote:

Hi,

I am in the process of understanding better how to find out which and how many VAST Seaside runtime images I have running on a (Linux based) Web Server and what I could do to start/stop some of them. This is important fur hot updates and stuff on a Web Server. I understand this will be a long learning process, but I need to start somewhere and understand little pieces one by one ;-)

So my current approach is very basic and my knowledge is very limited.

I usually do a
ps x | grep es

to see how many images I have running.

Interestingly, it seems starting one VM with an image shows 4 processes: the shell script that started an image and three instances of esnx.
Why do I see three esnx processes running? One of them has a status of "sl", the other two "s". What is each of them doing, why are there 3 processes at all? Am I using the wrong ps parameter?

When I issue a kill command, some of these three die immediately, one of them also drags another one to death whan it dies, and one of them always needs a kill -9. What does that mean?

This was the easy part.

Thinking into the future, I need a way to stop/update/restart one of several running images at a time (each of them listening onto another port) (I know there's gouing to be more to this, like telling apache not to dispatch to that image for a while and such). So the easiest and maybe lowest tech solution would be to kill the processes of only the image I want to update. One solution could be to write a file on image startup that contains the port number and the PID of the running process. This brings up a few questions:

* How do I find the current PID in my Smalltalk image?
* Can I find out all the PIDs of all three processes and store them in the file?
* Is there a way to kill a VM so that all processes die together? Which PID is the one I am looking for?

There sure are better ways to handle all this updating stuff and I remember seeing a blog post on how somebody solved the problem in Perl with Apache. So if anybody has some good suggestions, I'm happy to learn!

Joachim

On Wednesday, June 27, 2012 10:27:17 AM UTC-4, Louis LaBrunda wrote:
Hi Joachim and John,

I use this in windows:

pId := OSCall new getCurrentProcessId.

as OSCall is platform specific, it may contain a UNIX version of the code that works.

Lou


On Wednesday, June 27, 2012 10:04:42 AM UTC-4, John O'Keefe wrote:
Joachim -
 
When you start the first VA Smalltalk executable on Linux you will normally get 4 processes; starting additional VA Smalltalk executables normally adds 3 processes per executable. The processes are:
  • main process (the one running the image)
  • break button process
  • process server process (see UnixProcess>>#execProcess)
  • shared memory process
If you specify the -no_break command line parameter when starting the VA Smalltalk image, you should not get the break button process.
 
The shared memory process (there is only one) will hang around for a while (but not forever) even after the last VA Smalltalk executable is stopped. It does this so the shared memory bits (the stuff in /temp/es) doesn't have to be recreated if you decide to start a VA Smalltalk executable some time soon after shutting down the last VA Smalltalk executable. There is no real need to kill this process -- it will shutdown eventually (I don't remember the timeout value, but I can look it up if it is important).
 
The pid of the main process is written to the log file when the image is started -- not too convenient if you want to access it from the image. You can get the pid of the main process by adding a method (since I can't find any method in the image that sends this primitive):
 
EsSystemInfo class>>#pid
  "Answer the pid of the main process."
 
  <primitive: VMprSysInfoGetPid>
  ^ self primitiveFailed
 
The other 3 pids are not exposed to the image.
 
Killing the main process should kill all but the shared memory process.
 
I'll add this method into V8.5.2.
 
John
 

On Wednesday, June 27, 2012 8:08:07 AM UTC-4, [hidden email] wrote:

Hi,

I am in the process of understanding better how to find out which and how many VAST Seaside runtime images I have running on a (Linux based) Web Server and what I could do to start/stop some of them. This is important fur hot updates and stuff on a Web Server. I understand this will be a long learning process, but I need to start somewhere and understand little pieces one by one ;-)

So my current approach is very basic and my knowledge is very limited.

I usually do a
ps x | grep es

to see how many images I have running.

Interestingly, it seems starting one VM with an image shows 4 processes: the shell script that started an image and three instances of esnx.
Why do I see three esnx processes running? One of them has a status of "sl", the other two "s". What is each of them doing, why are there 3 processes at all? Am I using the wrong ps parameter?

When I issue a kill command, some of these three die immediately, one of them also drags another one to death whan it dies, and one of them always needs a kill -9. What does that mean?

This was the easy part.

Thinking into the future, I need a way to stop/update/restart one of several running images at a time (each of them listening onto another port) (I know there's gouing to be more to this, like telling apache not to dispatch to that image for a while and such). So the easiest and maybe lowest tech solution would be to kill the processes of only the image I want to update. One solution could be to write a file on image startup that contains the port number and the PID of the running process. This brings up a few questions:

* How do I find the current PID in my Smalltalk image?
* Can I find out all the PIDs of all three processes and store them in the file?
* Is there a way to kill a VM so that all processes die together? Which PID is the one I am looking for?

There sure are better ways to handle all this updating stuff and I remember seeing a blog post on how somebody solved the problem in Perl with Apache. So if anybody has some good suggestions, I'm happy to learn!

Joachim

On Wednesday, June 27, 2012 10:04:42 AM UTC-4, John O'Keefe wrote:
Joachim -
 
When you start the first VA Smalltalk executable on Linux you will normally get 4 processes; starting additional VA Smalltalk executables normally adds 3 processes per executable. The processes are:
  • main process (the one running the image)
  • break button process
  • process server process (see UnixProcess>>#execProcess)
  • shared memory process
If you specify the -no_break command line parameter when starting the VA Smalltalk image, you should not get the break button process.
 
The shared memory process (there is only one) will hang around for a while (but not forever) even after the last VA Smalltalk executable is stopped. It does this so the shared memory bits (the stuff in /temp/es) doesn't have to be recreated if you decide to start a VA Smalltalk executable some time soon after shutting down the last VA Smalltalk executable. There is no real need to kill this process -- it will shutdown eventually (I don't remember the timeout value, but I can look it up if it is important).
 
The pid of the main process is written to the log file when the image is started -- not too convenient if you want to access it from the image. You can get the pid of the main process by adding a method (since I can't find any method in the image that sends this primitive):
 
EsSystemInfo class>>#pid
  "Answer the pid of the main process."
 
  <primitive: VMprSysInfoGetPid>
  ^ self primitiveFailed
 
The other 3 pids are not exposed to the image.
 
Killing the main process should kill all but the shared memory process.
 
I'll add this method into V8.5.2.
 
John
 

On Wednesday, June 27, 2012 8:08:07 AM UTC-4, [hidden email] wrote:

Hi,

I am in the process of understanding better how to find out which and how many VAST Seaside runtime images I have running on a (Linux based) Web Server and what I could do to start/stop some of them. This is important fur hot updates and stuff on a Web Server. I understand this will be a long learning process, but I need to start somewhere and understand little pieces one by one ;-)

So my current approach is very basic and my knowledge is very limited.

I usually do a
ps x | grep es

to see how many images I have running.

Interestingly, it seems starting one VM with an image shows 4 processes: the shell script that started an image and three instances of esnx.
Why do I see three esnx processes running? One of them has a status of "sl", the other two "s". What is each of them doing, why are there 3 processes at all? Am I using the wrong ps parameter?

When I issue a kill command, some of these three die immediately, one of them also drags another one to death whan it dies, and one of them always needs a kill -9. What does that mean?

This was the easy part.

Thinking into the future, I need a way to stop/update/restart one of several running images at a time (each of them listening onto another port) (I know there's gouing to be more to this, like telling apache not to dispatch to that image for a while and such). So the easiest and maybe lowest tech solution would be to kill the processes of only the image I want to update. One solution could be to write a file on image startup that contains the port number and the PID of the running process. This brings up a few questions:

* How do I find the current PID in my Smalltalk image?
* Can I find out all the PIDs of all three processes and store them in the file?
* Is there a way to kill a VM so that all processes die together? Which PID is the one I am looking for?

There sure are better ways to handle all this updating stuff and I remember seeing a blog post on how somebody solved the problem in Perl with Apache. So if anybody has some good suggestions, I'm happy to learn!

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/Ga7tuNciHVgJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: Understanding Linux Processes with VAST

John O'Keefe-3
In reply to this post by jtuchel
Lou and Joachim -
There is no equivalent call implemented in the Unix image. Using the method I provided is platform-independent - it does GetCurrentProcessID() (Windows) or getpid() (Unix).
John
On Wednesday, June 27, 2012 10:49:26 AM UTC-4, [hidden email] wrote:
Thanks Lou,

I'll see if it's available on Linux, but I guess it isn't, based on John's answer.

Joachim

Am Mittwoch, 27. Juni 2012 16:27:17 UTC+2 schrieb Louis LaBrunda:
Hi Joachim and John,

I use this in windows:

pId := OSCall new getCurrentProcessId.

as OSCall is platform specific, it may contain a UNIX version of the code that works.

Lou


On Wednesday, June 27, 2012 10:04:42 AM UTC-4, John O'Keefe wrote:
Joachim -
 
When you start the first VA Smalltalk executable on Linux you will normally get 4 processes; starting additional VA Smalltalk executables normally adds 3 processes per executable. The processes are:
  • main process (the one running the image)
  • break button process
  • process server process (see UnixProcess>>#execProcess)
  • shared memory process
If you specify the -no_break command line parameter when starting the VA Smalltalk image, you should not get the break button process.
 
The shared memory process (there is only one) will hang around for a while (but not forever) even after the last VA Smalltalk executable is stopped. It does this so the shared memory bits (the stuff in /temp/es) doesn't have to be recreated if you decide to start a VA Smalltalk executable some time soon after shutting down the last VA Smalltalk executable. There is no real need to kill this process -- it will shutdown eventually (I don't remember the timeout value, but I can look it up if it is important).
 
The pid of the main process is written to the log file when the image is started -- not too convenient if you want to access it from the image. You can get the pid of the main process by adding a method (since I can't find any method in the image that sends this primitive):
 
EsSystemInfo class>>#pid
  "Answer the pid of the main process."
 
  <primitive: VMprSysInfoGetPid>
  ^ self primitiveFailed
 
The other 3 pids are not exposed to the image.
 
Killing the main process should kill all but the shared memory process.
 
I'll add this method into V8.5.2.
 
John
 

On Wednesday, June 27, 2012 8:08:07 AM UTC-4, [hidden email] wrote:

Hi,

I am in the process of understanding better how to find out which and how many VAST Seaside runtime images I have running on a (Linux based) Web Server and what I could do to start/stop some of them. This is important fur hot updates and stuff on a Web Server. I understand this will be a long learning process, but I need to start somewhere and understand little pieces one by one ;-)

So my current approach is very basic and my knowledge is very limited.

I usually do a
ps x | grep es

to see how many images I have running.

Interestingly, it seems starting one VM with an image shows 4 processes: the shell script that started an image and three instances of esnx.
Why do I see three esnx processes running? One of them has a status of "sl", the other two "s". What is each of them doing, why are there 3 processes at all? Am I using the wrong ps parameter?

When I issue a kill command, some of these three die immediately, one of them also drags another one to death whan it dies, and one of them always needs a kill -9. What does that mean?

This was the easy part.

Thinking into the future, I need a way to stop/update/restart one of several running images at a time (each of them listening onto another port) (I know there's gouing to be more to this, like telling apache not to dispatch to that image for a while and such). So the easiest and maybe lowest tech solution would be to kill the processes of only the image I want to update. One solution could be to write a file on image startup that contains the port number and the PID of the running process. This brings up a few questions:

* How do I find the current PID in my Smalltalk image?
* Can I find out all the PIDs of all three processes and store them in the file?
* Is there a way to kill a VM so that all processes die together? Which PID is the one I am looking for?

There sure are better ways to handle all this updating stuff and I remember seeing a blog post on how somebody solved the problem in Perl with Apache. So if anybody has some good suggestions, I'm happy to learn!

Joachim

On Wednesday, June 27, 2012 10:04:42 AM UTC-4, John O'Keefe wrote:
Joachim -
 
When you start the first VA Smalltalk executable on Linux you will normally get 4 processes; starting additional VA Smalltalk executables normally adds 3 processes per executable. The processes are:
  • main process (the one running the image)
  • break button process
  • process server process (see UnixProcess>>#execProcess)
  • shared memory process
If you specify the -no_break command line parameter when starting the VA Smalltalk image, you should not get the break button process.
 
The shared memory process (there is only one) will hang around for a while (but not forever) even after the last VA Smalltalk executable is stopped. It does this so the shared memory bits (the stuff in /temp/es) doesn't have to be recreated if you decide to start a VA Smalltalk executable some time soon after shutting down the last VA Smalltalk executable. There is no real need to kill this process -- it will shutdown eventually (I don't remember the timeout value, but I can look it up if it is important).
 
The pid of the main process is written to the log file when the image is started -- not too convenient if you want to access it from the image. You can get the pid of the main process by adding a method (since I can't find any method in the image that sends this primitive):
 
EsSystemInfo class>>#pid
  "Answer the pid of the main process."
 
  <primitive: VMprSysInfoGetPid>
  ^ self primitiveFailed
 
The other 3 pids are not exposed to the image.
 
Killing the main process should kill all but the shared memory process.
 
I'll add this method into V8.5.2.
 
John
 

On Wednesday, June 27, 2012 8:08:07 AM UTC-4, [hidden email] wrote:

Hi,

I am in the process of understanding better how to find out which and how many VAST Seaside runtime images I have running on a (Linux based) Web Server and what I could do to start/stop some of them. This is important fur hot updates and stuff on a Web Server. I understand this will be a long learning process, but I need to start somewhere and understand little pieces one by one ;-)

So my current approach is very basic and my knowledge is very limited.

I usually do a
ps x | grep es

to see how many images I have running.

Interestingly, it seems starting one VM with an image shows 4 processes: the shell script that started an image and three instances of esnx.
Why do I see three esnx processes running? One of them has a status of "sl", the other two "s". What is each of them doing, why are there 3 processes at all? Am I using the wrong ps parameter?

When I issue a kill command, some of these three die immediately, one of them also drags another one to death whan it dies, and one of them always needs a kill -9. What does that mean?

This was the easy part.

Thinking into the future, I need a way to stop/update/restart one of several running images at a time (each of them listening onto another port) (I know there's gouing to be more to this, like telling apache not to dispatch to that image for a while and such). So the easiest and maybe lowest tech solution would be to kill the processes of only the image I want to update. One solution could be to write a file on image startup that contains the port number and the PID of the running process. This brings up a few questions:

* How do I find the current PID in my Smalltalk image?
* Can I find out all the PIDs of all three processes and store them in the file?
* Is there a way to kill a VM so that all processes die together? Which PID is the one I am looking for?

There sure are better ways to handle all this updating stuff and I remember seeing a blog post on how somebody solved the problem in Perl with Apache. So if anybody has some good suggestions, I'm happy to learn!

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/Evk-cxtv454J.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: Understanding Linux Processes with VAST

Thomas Koschate-2
In reply to this post by jtuchel
On Wednesday, June 27, 2012 8:08:07 AM UTC-4, [hidden email] wrote:

I am in the process of understanding better how to find out which and how many VAST Seaside runtime images I have running on a (Linux based) Web Server and what I could do to start/stop some of them.

I went through some of this just recently.  It turns out it's not that difficult to run a headless image as a service.  Most of the script distributed with VA is dedicated to making sure that the environment isn't loaded up multiple times and that it's flexible.  If you're setting up a production machine, you have full control over all of that anyway.

I created a script, creatively named "usbMonitor":

#!/bin/bash
cd /usr/local/usbMonitor
export PATH=/usr/local/usbMonitor/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/usbMonitor/bin:$LD_LIBRARY_PATH
esnx -platform MOTIF -no_break -i usbMonitor.icx -ini:usbMonitor.ini HcmUSBMonitorServer
 
In the /usr/local/usbMonitor directory, I placed the .ini and .icx files.  I also created the bin, nls and xml directories and populated them appropriately.  In my case, I'm installing onto boxes that have no development environment, and my service is the only Smalltalk running on them.  You may find it preferable to explore an alternate directory structure, or possibly use links to eliminate redundancy.

Look around in your /etc/init.d directory for a service script that does most of what you need (in my distro, messagebus wasn't too far off), and modify it to use your script, and you should be good to go.

As Brad suggests, keeping each image in its own directory may simplify your life, or you could get creative with link names and the use of $0 in your scripts.

Tom

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/ZbZf-Z_YgMYJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: Understanding Linux Processes with VAST

jtuchel
In reply to this post by jtuchel
Tom,

thanks for your ideas.
It's another case of not seeing the forest between all those trees. Starting and stopping the images as daemons is probably the most obvious thing to do. That's why I never thought about it seriously ;-)
I've built the respective scripts for starting and stopping emsrv on a Linux machine in the past and have them in daily use, so I have all the building blocks available...

So the next hurdle is going to be how to tell Apache to not dispatch to a certain image (or several thereof), preferably without breaking the current running sessions, and how to determine that an image has been let go by Apache so that I can stop it...

But one brick at a time, the building is slowly being erected, thanks to your valuable input!

Joachim



Am Mittwoch, 27. Juni 2012 14:08:07 UTC+2 schrieb [hidden email]:
Hi,

I am in the process of understanding better how to find out which and how many VAST Seaside runtime images I have running on a (Linux based) Web Server and what I could do to start/stop some of them. This is important fur hot updates and stuff on a Web Server. I understand this will be a long learning process, but I need to start somewhere and understand little pieces one by one ;-)

So my current approach is very basic and my knowledge is very limited.

I usually do a
ps x | grep es

to see how many images I have running.

Interestingly, it seems starting one VM with an image shows 4 processes: the shell script that started an image and three instances of esnx.
Why do I see three esnx processes running? One of them has a status of "sl", the other two "s". What is each of them doing, why are there 3 processes at all? Am I using the wrong ps parameter?

When I issue a kill command, some of these three die immediately, one of them also drags another one to death whan it dies, and one of them always needs a kill -9. What does that mean?

This was the easy part.

Thinking into the future, I need a way to stop/update/restart one of several running images at a time (each of them listening onto another port) (I know there's gouing to be more to this, like telling apache not to dispatch to that image for a while and such). So the easiest and maybe lowest tech solution would be to kill the processes of only the image I want to update. One solution could be to write a file on image startup that contains the port number and the PID of the running process. This brings up a few questions:

* How do I find the current PID in my Smalltalk image?
* Can I find out all the PIDs of all three processes and store them in the file?
* Is there a way to kill a VM so that all processes die together? Which PID is the one I am looking for?

There sure are better ways to handle all this updating stuff and I remember seeing a blog post on how somebody solved the problem in Perl with Apache. So if anybody has some good suggestions, I'm happy to learn!

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/ykkX9CXi4vAJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.