Understanding Linux Processes with VAST

• main process (the one running the image)
• break button process
• process server process (see UnixProcess>>#execProcess)
• shared memory process

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

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

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

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

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
> --

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

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

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

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

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

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

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

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.

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