Smalltalk › Gemtalk › GLASS

Cannot backup anymore while Seaside gems are running

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

11 messages Options

GLASS mailing list

Cannot backup anymore while Seaside gems are running

Hi,

Previously I was able to make backups while my Seaside gems were running. Now, whenever I try to make a backup while they are running, I get this error:

'Please wait until system is no longer voting and try again'

Of course I get that error even after shutting down the stone and starting again. And even waiting for a long time.

The way I make the backups are:

$GS_HOME/bin/todeIt $stoneName bu backup --commit $backupfile

Both `system.conf` and `gem.conf` have this setting:

$GS_HOME/bin/todeIt $stoneName bu backup --commit $backupfile

Now...if I shut down the seaside gems, the backup does work.

Any idea what I am doing wrong? I am on GemStone 3.3.3.

Thanks,

Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

GLASS mailing list

Re: Cannot backup anymore while Seaside gems are running

Mariano,

The `Please wait...` message is displayed, because voting is ongoing, or another process is holding onto the gc lock (see TDGemStoneTool>>systemIsVoting):

systemIsVoting
    | vs sessId |
    vs := System voteState.
    sessId := System sessionIdHoldingGcLock.
    ^ sessId ~= 0 or: [ vs > 0 and: [ vs < 4 ] ]

It would probably help the see what the voteState is and which session is holding the GcLock. You could pass those results along as soon as you get them.

The next step will be to supply us with some statmon files and your log files that cover a failed backup.

Dale

PS: if you look at the man page for the backup command (`man bu backup`), you'll see a line near the bottom that looks like this:

browse method --spec `TDGemStoneTool>>bubackup`

All man pages should have a line like this (not all have this yet:) that will take you directly to the method that implements the command .. then you can set a breakpoint in the that method for debugging/understanding what's going on in a command ... I know that in this case it wouldn't necessarily solve the problem, but I did figure it was worth pointing out for future reference ...

On 02/06/2017 07:27 AM, Mariano Martinez Peck via Glass wrote:

Hi,

Previously I was able to make backups while my Seaside gems were running. Now, whenever I try to make a backup while they are running, I get this error:

'Please wait until system is no longer voting and try again'

Of course I get that error even after shutting down the stone and starting again. And even waiting for a long time.

The way I make the backups are:

$GS_HOME/bin/todeIt $stoneName bu backup --commit $backupfile

Both `system.conf` and `gem.conf` have this setting:

$GS_HOME/bin/todeIt $stoneName bu backup --commit $backupfile

Now...if I shut down the seaside gems, the backup does work.

Any idea what I am doing wrong? I am on GemStone 3.3.3.

Thanks,

--

Mariano
http://marianopeck.wordpress.com
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

GLASS mailing list

Re: Cannot backup anymore while Seaside gems are running

oh, and I think I will make some changes to the `bu backup` command ... first instead of just printing the the `Please wait ...` message, I will include the voteState and or session holding gc lock in the message ... I will also add a `--wait` so that the backup will wait until the voting is completed before making the backup ... at least then the `bu backup` command can be used in a cron job and ensure that the backup gets executed as soon as voting is complete ...

Dale

On 02/06/2017 08:47 AM, Dale Henrichs wrote:

Mariano,

The `Please wait...` message is displayed, because voting is ongoing, or another process is holding onto the gc lock (see TDGemStoneTool>>systemIsVoting):

systemIsVoting
    | vs sessId |
    vs := System voteState.
    sessId := System sessionIdHoldingGcLock.
    ^ sessId ~= 0 or: [ vs > 0 and: [ vs < 4 ] ]

It would probably help the see what the voteState is and which session is holding the GcLock. You could pass those results along as soon as you get them.

The next step will be to supply us with some statmon files and your log files that cover a failed backup.

Dale
PS: if you look at the man page for the backup command (`man bu backup`), you'll see a line near the bottom that looks like this:

browse method --spec `TDGemStoneTool>>bubackup`

All man pages should have a line like this (not all have this yet:) that will take you directly to the method that implements the command .. then you can set a breakpoint in the that method for debugging/understanding what's going on in a command ... I know that in this case it wouldn't necessarily solve the problem, but I did figure it was worth pointing out for future reference ...

On 02/06/2017 07:27 AM, Mariano Martinez Peck via Glass wrote:
Hi,

Previously I was able to make backups while my Seaside gems were running. Now, whenever I try to make a backup while they are running, I get this error:

'Please wait until system is no longer voting and try again'

Of course I get that error even after shutting down the stone and starting again. And even waiting for a long time.

The way I make the backups are:

$GS_HOME/bin/todeIt $stoneName bu backup --commit $backupfile

Both `system.conf` and `gem.conf` have this setting:

$GS_HOME/bin/todeIt $stoneName bu backup --commit $backupfile

Now...if I shut down the seaside gems, the backup does work.

Any idea what I am doing wrong? I am on GemStone 3.3.3.

Thanks,

--

Mariano
http://marianopeck.wordpress.com
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

GLASS mailing list

Re: Cannot backup anymore while Seaside gems are running

On Mon, Feb 6, 2017 at 1:52 PM, Dale Henrichs via Glass <[hidden email]> wrote:

oh, and I think I will make some changes to the `bu backup` command ... first instead of just printing the the `Please wait ...` message, I will include the voteState and or session holding gc lock in the message ... I will also add a `--wait` so that the backup will wait until the voting is completed before making the backup ... at least then the `bu backup` command can be used in a cron job and ensure that the backup gets executed as soon as voting is complete ...

OK. I think the --wait is exactly what I need. Because on my cron job, I fire the cleaning (MFC included) and then the `bu backup`. So...my next question was going to be ... "how can I then wait until vote is done so that my backup script work".

Great. I will wait for your changes then.

BTW, do you know why it worked for me before? I was doing the fullCompressedBackup: myself... (rather than `bu backup`) so I was not validating any voteState explicitly. Could that be the difference?

Thanks in advance,

Dale
On 02/06/2017 08:47 AM, Dale Henrichs wrote:
Mariano,

The `Please wait...` message is displayed, because voting is ongoing, or another process is holding onto the gc lock (see TDGemStoneTool>>systemIsVoting):

systemIsVoting
    | vs sessId |
    vs := System voteState.
    sessId := System sessionIdHoldingGcLock.
    ^ sessId ~= 0 or: [ vs > 0 and: [ vs < 4 ] ]

It would probably help the see what the voteState is and which session is holding the GcLock. You could pass those results along as soon as you get them.

The next step will be to supply us with some statmon files and your log files that cover a failed backup.

Dale
PS: if you look at the man page for the backup command (`man bu backup`), you'll see a line near the bottom that looks like this:

browse method --spec `TDGemStoneTool>>bubackup`

All man pages should have a line like this (not all have this yet:) that will take you directly to the method that implements the command .. then you can set a breakpoint in the that method for debugging/understanding what's going on in a command ... I know that in this case it wouldn't necessarily solve the problem, but I did figure it was worth pointing out for future reference ...

On 02/06/2017 07:27 AM, Mariano Martinez Peck via Glass wrote:
Hi,

Previously I was able to make backups while my Seaside gems were running. Now, whenever I try to make a backup while they are running, I get this error:

'Please wait until system is no longer voting and try again'

Of course I get that error even after shutting down the stone and starting again. And even waiting for a long time.

The way I make the backups are:

$GS_HOME/bin/todeIt $stoneName bu backup --commit $backupfile

Both `system.conf` and `gem.conf` have this setting:

$GS_HOME/bin/todeIt $stoneName bu backup --commit $backupfile

Now...if I shut down the seaside gems, the backup does work.

Any idea what I am doing wrong? I am on GemStone 3.3.3.

Thanks,

--

Mariano
http://marianopeck.wordpress.com
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

GLASS mailing list

Re: Cannot backup anymore while Seaside gems are running

In reply to this post by GLASS mailing list

On Mon, Feb 6, 2017 at 1:47 PM, Dale Henrichs via Glass <[hidden email]> wrote:

Mariano,

The `Please wait...` message is displayed, because voting is ongoing, or another process is holding onto the gc lock (see TDGemStoneTool>>systemIsVoting):

systemIsVoting
    | vs sessId |
    vs := System voteState.
    sessId := System sessionIdHoldingGcLock.
    ^ sessId ~= 0 or: [ vs > 0 and: [ vs < 4 ] ]

It would probably help the see what the voteState is and which session is holding the GcLock. You could pass those results along as soon as you get them.

Thanks. The voteState was 2. And yes, after some times, voteState started giving 0. Once that happened, I was able to make the backup..

The next step will be to supply us with some statmon files and your log files that cover a failed backup.

Dale
PS: if you look at the man page for the backup command (`man bu backup`), you'll see a line near the bottom that looks like this:

browse method --spec `TDGemStoneTool>>bubackup`

All man pages should have a line like this (not all have this yet:) that will take you directly to the method that implements the command .. then you can set a breakpoint in the that method for debugging/understanding what's going on in a command ... I know that in this case it wouldn't necessarily solve the problem, but I did figure it was worth pointing out for future reference ...

On 02/06/2017 07:27 AM, Mariano Martinez Peck via Glass wrote:
Hi,

Previously I was able to make backups while my Seaside gems were running. Now, whenever I try to make a backup while they are running, I get this error:

'Please wait until system is no longer voting and try again'

Of course I get that error even after shutting down the stone and starting again. And even waiting for a long time.

The way I make the backups are:

$GS_HOME/bin/todeIt $stoneName bu backup --commit $backupfile

Both `system.conf` and `gem.conf` have this setting:

$GS_HOME/bin/todeIt $stoneName bu backup --commit $backupfile

Now...if I shut down the seaside gems, the backup does work.

Any idea what I am doing wrong? I am on GemStone 3.3.3.

Thanks,

--

Mariano
http://marianopeck.wordpress.com
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

GLASS mailing list

Re: Cannot backup anymore while Seaside gems are running

In reply to this post by GLASS mailing list

Mariano,

A call to #fullCompressedBackup: would have failed with a "failed to acquire gc lock error message" so what appears to be happening now is that you hit a gc operation that was taking a long time to complete ... we know that if you have symbol gc enabled it can take a noticeable amount of time to gc symbols if you have a lot of dead symbols to deal with ... there are other operations (getting the voteState and the session id holding the lock (plus stats and log files) would allow us to determine just what was going on ...

Voting is not the only operation that could prevent a backup from running. Both an object audit or list instances acquires the gc lock and would prevent a backup from running with a voteState of 0, I will probably check for the gc lock as part of the `--wait` option, but I'm not sure that I will wait for the lock to be freed in those cases .... we'll cross that bridge when we come to it:)

Dale

On 02/06/2017 09:12 AM, Mariano Martinez Peck wrote:

On Mon, Feb 6, 2017 at 1:52 PM, Dale Henrichs via Glass <[hidden email]> wrote:

oh, and I think I will make some changes to the `bu backup` command ... first instead of just printing the the `Please wait ...` message, I will include the voteState and or session holding gc lock in the message ... I will also add a `--wait` so that the backup will wait until the voting is completed before making the backup ... at least then the `bu backup` command can be used in a cron job and ensure that the backup gets executed as soon as voting is complete ...

OK. I think the --wait is exactly what I need. Because on my cron job, I fire the cleaning (MFC included) and then the `bu backup`. So...my next question was going to be ... "how can I then wait until vote is done so that my backup script work".

Great. I will wait for your changes then.

BTW, do you know why it worked for me before? I was doing the fullCompressedBackup: myself... (rather than `bu backup`) so I was not validating any voteState explicitly. Could that be the difference?

Thanks in advance,
Dale
On 02/06/2017 08:47 AM, Dale Henrichs wrote:
Mariano,

The `Please wait...` message is displayed, because voting is ongoing, or another process is holding onto the gc lock (see TDGemStoneTool>>systemIsVoting):

systemIsVoting
    | vs sessId |
    vs := System voteState.
    sessId := System sessionIdHoldingGcLock.
    ^ sessId ~= 0 or: [ vs > 0 and: [ vs < 4 ] ]

It would probably help the see what the voteState is and which session is holding the GcLock. You could pass those results along as soon as you get them.

The next step will be to supply us with some statmon files and your log files that cover a failed backup.

Dale
PS: if you look at the man page for the backup command (`man bu backup`), you'll see a line near the bottom that looks like this:

browse method --spec `TDGemStoneTool>>bubackup`

All man pages should have a line like this (not all have this yet:) that will take you directly to the method that implements the command .. then you can set a breakpoint in the that method for debugging/understanding what's going on in a command ... I know that in this case it wouldn't necessarily solve the problem, but I did figure it was worth pointing out for future reference ...

On 02/06/2017 07:27 AM, Mariano Martinez Peck via Glass wrote:
Hi,

Previously I was able to make backups while my Seaside gems were running. Now, whenever I try to make a backup while they are running, I get this error:

'Please wait until system is no longer voting and try again'

Of course I get that error even after shutting down the stone and starting again. And even waiting for a long time.

The way I make the backups are:

$GS_HOME/bin/todeIt $stoneName bu backup --commit $backupfile

Both `system.conf` and `gem.conf` have this setting:

$GS_HOME/bin/todeIt $stoneName bu backup --commit $backupfile

Now...if I shut down the seaside gems, the backup does work.

Any idea what I am doing wrong? I am on GemStone 3.3.3.

Thanks,

--

Mariano
http://marianopeck.wordpress.com
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass
--
Mariano http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

GLASS mailing list

Re: Cannot backup anymore while Seaside gems are running

In reply to this post by GLASS mailing list

On 02/06/2017 09:30 AM, Mariano Martinez Peck wrote:

On Mon, Feb 6, 2017 at 1:47 PM, Dale Henrichs via Glass <[hidden email]> wrote:

Mariano,

The `Please wait...` message is displayed, because voting is ongoing, or another process is holding onto the gc lock (see TDGemStoneTool>>systemIsVoting):

systemIsVoting
    | vs sessId |
    vs := System voteState.
    sessId := System sessionIdHoldingGcLock.
    ^ sessId ~= 0 or: [ vs > 0 and: [ vs < 4 ] ]

It would probably help the see what the voteState is and which session is holding the GcLock. You could pass those results along as soon as you get them.

Thanks. The voteState was 2. And yes, after some times, voteState started giving 0. Once that happened, I was able to make the backup..

Okay, I've pushed the `--wait` option to the dev branch ... let me know how it goes .

Dale

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

GLASS mailing list

Re: Cannot backup anymore while Seaside gems are running

In reply to this post by GLASS mailing list

On Mon, Feb 6, 2017 at 2:34 PM, Dale Henrichs <[hidden email]> wrote:

Mariano,

A call to #fullCompressedBackup: would have failed with a "failed to acquire gc lock error message" so what appears to be happening now is that you hit a gc operation that was taking a long time to complete ... we know that if you have symbol gc enabled it can take a noticeable amount of time to gc symbols if you have a lot of dead symbols to deal with ... there are other operations (getting the voteState and the session id holding the lock (plus stats and log files) would allow us to determine just what was going on ...

Ohh yes, another of the changes I did is to enable symbol GC as previously I was not able to set it because it was broken for that GemStone version.

Voting is not the only operation that could prevent a backup from running. Both an object audit or list instances acquires the gc lock and would prevent a backup from running with a voteState of 0, I will probably check for the gc lock as part of the `--wait` option, but I'm not sure that I will wait for the lock to be freed in those cases .... we'll cross that bridge when we come to it:)

Yes, I was aware of the gc lock part.

And yes, I think your logic is good for the moment with --wait.

Dale
On 02/06/2017 09:12 AM, Mariano Martinez Peck wrote:
On Mon, Feb 6, 2017 at 1:52 PM, Dale Henrichs via Glass <[hidden email]> wrote:

oh, and I think I will make some changes to the `bu backup` command ... first instead of just printing the the `Please wait ...` message, I will include the voteState and or session holding gc lock in the message ... I will also add a `--wait` so that the backup will wait until the voting is completed before making the backup ... at least then the `bu backup` command can be used in a cron job and ensure that the backup gets executed as soon as voting is complete ...

OK. I think the --wait is exactly what I need. Because on my cron job, I fire the cleaning (MFC included) and then the `bu backup`. So...my next question was going to be ... "how can I then wait until vote is done so that my backup script work".

Great. I will wait for your changes then.

BTW, do you know why it worked for me before? I was doing the fullCompressedBackup: myself... (rather than `bu backup`) so I was not validating any voteState explicitly. Could that be the difference?

Thanks in advance,
Dale
On 02/06/2017 08:47 AM, Dale Henrichs wrote:
Mariano,

The `Please wait...` message is displayed, because voting is ongoing, or another process is holding onto the gc lock (see TDGemStoneTool>>systemIsVoting):

systemIsVoting
    | vs sessId |
    vs := System voteState.
    sessId := System sessionIdHoldingGcLock.
    ^ sessId ~= 0 or: [ vs > 0 and: [ vs < 4 ] ]

It would probably help the see what the voteState is and which session is holding the GcLock. You could pass those results along as soon as you get them.

The next step will be to supply us with some statmon files and your log files that cover a failed backup.

Dale
PS: if you look at the man page for the backup command (`man bu backup`), you'll see a line near the bottom that looks like this:

browse method --spec `TDGemStoneTool>>bubackup`

All man pages should have a line like this (not all have this yet:) that will take you directly to the method that implements the command .. then you can set a breakpoint in the that method for debugging/understanding what's going on in a command ... I know that in this case it wouldn't necessarily solve the problem, but I did figure it was worth pointing out for future reference ...

On 02/06/2017 07:27 AM, Mariano Martinez Peck via Glass wrote:
Hi,

Previously I was able to make backups while my Seaside gems were running. Now, whenever I try to make a backup while they are running, I get this error:

'Please wait until system is no longer voting and try again'

Of course I get that error even after shutting down the stone and starting again. And even waiting for a long time.

The way I make the backups are:

$GS_HOME/bin/todeIt $stoneName bu backup --commit $backupfile

Both `system.conf` and `gem.conf` have this setting:

$GS_HOME/bin/todeIt $stoneName bu backup --commit $backupfile

Now...if I shut down the seaside gems, the backup does work.

Any idea what I am doing wrong? I am on GemStone 3.3.3.

Thanks,

--

Mariano
http://marianopeck.wordpress.com
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass
--
Mariano http://marianopeck.wordpress.com

Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

GLASS mailing list

Re: Cannot backup anymore while Seaside gems are running

In reply to this post by GLASS mailing list

On Mon, Feb 6, 2017 at 2:48 PM, Dale Henrichs <[hidden email]> wrote:

On 02/06/2017 09:30 AM, Mariano Martinez Peck wrote:

On Mon, Feb 6, 2017 at 1:47 PM, Dale Henrichs via Glass <[hidden email]> wrote:

Mariano,

The `Please wait...` message is displayed, because voting is ongoing, or another process is holding onto the gc lock (see TDGemStoneTool>>systemIsVoting):

systemIsVoting
    | vs sessId |
    vs := System voteState.
    sessId := System sessionIdHoldingGcLock.
    ^ sessId ~= 0 or: [ vs > 0 and: [ vs < 4 ] ]

It would probably help the see what the voteState is and which session is holding the GcLock. You could pass those results along as soon as you get them.

Thanks. The voteState was 2. And yes, after some times, voteState started giving 0. Once that happened, I was able to make the backup..

Okay, I've pushed the `--wait` option to the dev branch ... let me know how it goes .

Cool!

I am trying to update. But i have some questions...

1) On the server side I did:

`git pull origin dev`

Now, that only updates the filetree repo. How can I reload tODE on a given stone so that it greabs latest filetree state? Like below?

$GS_HOME/bin/todeIt $stoneName script --script=updateServerTode

2) Do I need to rebuild any image?

Thanks in advance,

Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

GLASS mailing list

Re: Cannot backup anymore while Seaside gems are running

On 02/06/2017 10:47 AM, Mariano Martinez Peck wrote:

On Mon, Feb 6, 2017 at 2:48 PM, Dale Henrichs <[hidden email]> wrote:

On 02/06/2017 09:30 AM, Mariano Martinez Peck wrote:

On Mon, Feb 6, 2017 at 1:47 PM, Dale Henrichs via Glass <[hidden email]> wrote:

Mariano,

The `Please wait...` message is displayed, because voting is ongoing, or another process is holding onto the gc lock (see TDGemStoneTool>>systemIsVoting):

systemIsVoting
    | vs sessId |
    vs := System voteState.
    sessId := System sessionIdHoldingGcLock.
    ^ sessId ~= 0 or: [ vs > 0 and: [ vs < 4 ] ]

It would probably help the see what the voteState is and which session is holding the GcLock. You could pass those results along as soon as you get them.

Thanks. The voteState was 2. And yes, after some times, voteState started giving 0. Once that happened, I was able to make the backup..

Okay, I've pushed the `--wait` option to the dev branch ... let me know how it goes .

Cool!

I am trying to update. But i have some questions...

1) On the server side I did:

`git pull origin dev`

Now, that only updates the filetree repo. How can I reload tODE on a given stone so that it greabs latest filetree state? Like below?

$GS_HOME/bin/todeIt $stoneName script --script=updateServerTode

This is the ticket...

2) Do I need to rebuild any image?

No client-side modifications, so no need to rebuild the client ...

Dale

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

GLASS mailing list

Re: Cannot backup anymore while Seaside gems are running

Thanks Dale, the new feature worked great. Thanks for such a fast improvement!

best,

On Mon, Feb 6, 2017 at 4:07 PM, Dale Henrichs <[hidden email]> wrote:

On 02/06/2017 10:47 AM, Mariano Martinez Peck wrote:

On Mon, Feb 6, 2017 at 2:48 PM, Dale Henrichs <[hidden email]> wrote:

On 02/06/2017 09:30 AM, Mariano Martinez Peck wrote:

On Mon, Feb 6, 2017 at 1:47 PM, Dale Henrichs via Glass <[hidden email]> wrote:

Mariano,

The `Please wait...` message is displayed, because voting is ongoing, or another process is holding onto the gc lock (see TDGemStoneTool>>systemIsVoting):

systemIsVoting
    | vs sessId |
    vs := System voteState.
    sessId := System sessionIdHoldingGcLock.
    ^ sessId ~= 0 or: [ vs > 0 and: [ vs < 4 ] ]

It would probably help the see what the voteState is and which session is holding the GcLock. You could pass those results along as soon as you get them.

Thanks. The voteState was 2. And yes, after some times, voteState started giving 0. Once that happened, I was able to make the backup..

Okay, I've pushed the `--wait` option to the dev branch ... let me know how it goes .

Cool!

I am trying to update. But i have some questions...

1) On the server side I did:

`git pull origin dev`

Now, that only updates the filetree repo. How can I reload tODE on a given stone so that it greabs latest filetree state? Like below?

$GS_HOME/bin/todeIt $stoneName script --script=updateServerTode

This is the ticket...

2) Do I need to rebuild any image?

No client-side modifications, so no need to rebuild the client ...

Dale

Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass