log reasons for vm exits

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

log reasons for vm exits

jtuchel
hi,

my vast/seaside image on a linux server sometimes exits without any indication of why it happened. It usually writes walkbacks and doesn't exit. But sometimes when i try to access it, all i get is a 503 from apache. According to uptime the machine didn't boot, so something must have killed the process, I guess.

So what i'd like to do is log the reason for exits, like a kill command. My hope is that I'll be able to at least exclude some possible reasons for the exit.

So how can I catch signals like sighup (or whatever signals a kill command may send) before the vm exits? Does the image even get these or does esnx exit without telling the image?

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/groups/opt_out.
Reply | Threaded
Open this post in threaded view
|

Re: log reasons for vm exits

John O'Keefe-3
Joachim -

All the signal handling is done in the VM. I will add an item to our 'futures' list to have the VM do the best it can to report on conditions that cause it to exit.

John

On Thursday, August 29, 2013 3:25:39 AM UTC-4, [hidden email] wrote:
hi,

my vast/seaside image on a linux server sometimes exits without any indication of why it happened. It usually writes walkbacks and doesn't exit. But sometimes when i try to access it, all i get is a 503 from apache. According to uptime the machine didn't boot, so something must have killed the process, I guess.

So what i'd like to do is log the reason for exits, like a kill command. My hope is that I'll be able to at least exclude some possible reasons for the exit.

So how can I catch signals like sighup (or whatever signals a kill command may send) before the vm exits? Does the image even get these or does esnx exit without telling the image?

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/groups/opt_out.
Reply | Threaded
Open this post in threaded view
|

Re: log reasons for vm exits

Marten Feldtmann-2
And how can I catch a signal ?

I have here C libraries throwing assert and VA simply dies under Linux and even unter Windows - no possibility to catch it and recover from that disaster ...

Marten


--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/groups/opt_out.
Reply | Threaded
Open this post in threaded view
|

Re: log reasons for vm exits

John O'Keefe-3
Marten -

As I told Joachim, with the current VA Smalltalk VM architecture, all signal handling is done inside the VM. So, you can't. This situation may change in the future.

John

On Thursday, August 29, 2013 4:03:21 PM UTC-4, Marten Feldtmann wrote:
And how can I catch a signal ?

I have here C libraries throwing assert and VA simply dies under Linux and even unter Windows - no possibility to catch it and recover from that disaster ...

Marten


--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/groups/opt_out.
Reply | Threaded
Open this post in threaded view
|

Re: log reasons for vm exits

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

thanks for clarifying. Would it be possible as a short-term solution to have the vm log such events. similar to vmtrap.log?

It's really a freightening thought that your new web service could die any second you neither know when nor why. At least knowing post mortem gives me a chance to look further.

Just to avoid a wrong impression: I have an image running on aLinux box for days without any problems. Sometimes even weeks. And then I have to stop it for maintenance reasons. BUT there are occasions when it dies for now obvious reason, sometimes mutliple times within a few hours.

Joachim

Am Donnerstag, 29. August 2013 21:15:54 UTC+2 schrieb John O'Keefe:
Joachim -

All the signal handling is done in the VM. I will add an item to our 'futures' list to have the VM do the best it can to report on conditions that cause it to exit.

John

On Thursday, August 29, 2013 3:25:39 AM UTC-4, [hidden email] wrote:
hi,

my vast/seaside image on a linux server sometimes exits without any indication of why it happened. It usually writes walkbacks and doesn't exit. But sometimes when i try to access it, all i get is a 503 from apache. According to uptime the machine didn't boot, so something must have killed the process, I guess.

So what i'd like to do is log the reason for exits, like a kill command. My hope is that I'll be able to at least exclude some possible reasons for the exit.

So how can I catch signals like sighup (or whatever signals a kill command may send) before the vm exits? Does the image even get these or does esnx exit without telling the image?

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/groups/opt_out.
Reply | Threaded
Open this post in threaded view
|

Re: log reasons for vm exits

Leo O.
In reply to this post by jtuchel
Hi Joachim,
We had a problem like you have. Our Seaside/Server Sockets application hanged up time to time. No walkback, only (but not ever) a wmtrap.log. 
This is my original post to the forum: https://groups.google.com/forum/#!topicsearchin/va-smalltalk/socket/va-smalltalk/9mR7AtAx_Mw
After days of investigations we found that the problem was generated by the use of: #whenTimeoutInMilliseconds:do: 
If this methods timeout when the VM was calling an external function (in our case, sockets functions), the VM exit without WB, or, as i said, only with vm logs.
Hope this could help you.
Leo

El jueves, 29 de agosto de 2013 04:25:39 UTC-3, [hidden email] escribió:
hi,

my vast/seaside image on a linux server sometimes exits without any indication of why it happened. It usually writes walkbacks and doesn't exit. But sometimes when i try to access it, all i get is a 503 from apache. According to uptime the machine didn't boot, so something must have killed the process, I guess.

So what i'd like to do is log the reason for exits, like a kill command. My hope is that I'll be able to at least exclude some possible reasons for the exit.

So how can I catch signals like sighup (or whatever signals a kill command may send) before the vm exits? Does the image even get these or does esnx exit without telling the image?

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/groups/opt_out.