Persistency problem with Pier 1.1.1 on Mac OS X Server
Locked
Persistency problem with Pier 1.1.1 on Mac OS X Server
 
|
Hello,
I have a Pier 1.1.1 installation running on our Mac OS X Server. While the Pier system runs just fine, I noticed that the system stopped saving the changes persistently to the image. After playing around a bit with our installation, I was able to reproduce the problem: - I start with a clean Pier image (and import content from a previous 1.1.1 installation using the Importer/Exporter component) - I choose PRImagePersistency (duration: 30 minutes; maxImages: 3) as the persistency scheme - I start changing the wiki - The first two saves work perfectly: Pier creates two new images + changes files - When the third backup should be made, I get an error: pier.image not found - I also tried to manually save the image, but get a similar error: Squeak cannot locate the changes file /...../pier.changes. - I checked: both files are where they should be Kind regards, Andy _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Re: Persistency problem with Pier 1.1.1 on Mac OS X Server
|
|
We are running several instances on a Mac Server here.
Are you sure that the VM has write permissions? Especially if you run the one-click image from /Applications, the VM has usually only limited write access. Lukas On Wed, Apr 29, 2009 at 10:11 AM, Andy Kellens <[hidden email]> wrote: > Hello, > > I have a Pier 1.1.1 installation running on our Mac OS X Server. > While the Pier system runs just fine, I noticed that the system stopped > saving the changes persistently to the image. > After playing around a bit with our installation, I was able to reproduce > the problem: > - I start with a clean Pier image (and import content from a previous > 1.1.1 installation using the Importer/Exporter component) > - I choose PRImagePersistency (duration: 30 minutes; maxImages: 3) as > the persistency scheme > - I start changing the wiki > - The first two saves work perfectly: Pier creates two new images + > changes files > - When the third backup should be made, I get an error: pier.image > not found > - I also tried to manually save the image, but get a similar error: > Squeak cannot locate the changes file /...../pier.changes. > - I checked: both files are where they should be > > Kind regards, > > Andy > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Re: Persistency problem with Pier 1.1.1 on Mac OS X Server
|
|
I checked: the VM has write permissions to the entire .app directory.
Kind regards, Andy On 29 Apr 2009, at 10:31, Lukas Renggli wrote: > We are running several instances on a Mac Server here. > > Are you sure that the VM has write permissions? Especially if you run > the one-click image from /Applications, the VM has usually only > limited write access. > > Lukas > > On Wed, Apr 29, 2009 at 10:11 AM, Andy Kellens <[hidden email]> > wrote: >> Hello, >> >> I have a Pier 1.1.1 installation running on our Mac OS X Server. >> While the Pier system runs just fine, I noticed that the system >> stopped >> saving the changes persistently to the image. >> After playing around a bit with our installation, I was able to >> reproduce >> the problem: >> - I start with a clean Pier image (and import content from a >> previous >> 1.1.1 installation using the Importer/Exporter component) >> - I choose PRImagePersistency (duration: 30 minutes; >> maxImages: 3) as >> the persistency scheme >> - I start changing the wiki >> - The first two saves work perfectly: Pier creates two new >> images + >> changes files >> - When the third backup should be made, I get an error: >> pier.image >> not found >> - I also tried to manually save the image, but get a similar >> error: >> Squeak cannot locate the changes file /...../pier.changes. >> - I checked: both files are where they should be >> >> Kind regards, >> >> Andy >> >> _______________________________________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Re: Persistency problem with Pier 1.1.1 on Mac OS X Server
|
|
Can you post a full stack trace?
On Wed, Apr 29, 2009 at 10:39 AM, Andy Kellens <[hidden email]> wrote: > I checked: the VM has write permissions to the entire .app directory. > > Kind regards, > > Andy > > On 29 Apr 2009, at 10:31, Lukas Renggli wrote: > >> We are running several instances on a Mac Server here. >> >> Are you sure that the VM has write permissions? Especially if you run >> the one-click image from /Applications, the VM has usually only >> limited write access. >> >> Lukas >> >> On Wed, Apr 29, 2009 at 10:11 AM, Andy Kellens <[hidden email]> wrote: >>> >>> Hello, >>> >>> I have a Pier 1.1.1 installation running on our Mac OS X Server. >>> While the Pier system runs just fine, I noticed that the system stopped >>> saving the changes persistently to the image. >>> After playing around a bit with our installation, I was able to reproduce >>> the problem: >>> - I start with a clean Pier image (and import content from a >>> previous >>> 1.1.1 installation using the Importer/Exporter component) >>> - I choose PRImagePersistency (duration: 30 minutes; maxImages: 3) >>> as >>> the persistency scheme >>> - I start changing the wiki >>> - The first two saves work perfectly: Pier creates two new images + >>> changes files >>> - When the third backup should be made, I get an error: pier.image >>> not found >>> - I also tried to manually save the image, but get a similar error: >>> Squeak cannot locate the changes file /...../pier.changes. >>> - I checked: both files are where they should be >>> >>> Kind regards, >>> >>> Andy >>> >>> _______________________________________________ >>> Magritte, Pier and Related Tools ... >>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >>> >> >> >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Re: Persistency problem with Pier 1.1.1 on Mac OS X Server
|
|
Hi,
I get a pop-up from squeak (see attached screenshot) and I managed to see the error, but I can't open up the actual debugger (the pop-up window just keeps appearing). I have seen that the old image (pier.image and pier.changes) get renamed, but apparently the system is not able to create the new pier.image and pier.changes. To be sure, I verified that squeak has write privileges to the correct directory. Cheers, Andy On 29 Apr 2009, at 11:10, Lukas Renggli wrote: > Can you post a full stack trace? > > On Wed, Apr 29, 2009 at 10:39 AM, Andy Kellens <[hidden email]> > wrote: >> I checked: the VM has write permissions to the entire .app directory. >> >> Kind regards, >> >> Andy >> >> On 29 Apr 2009, at 10:31, Lukas Renggli wrote: >> >>> We are running several instances on a Mac Server here. >>> >>> Are you sure that the VM has write permissions? Especially if you >>> run >>> the one-click image from /Applications, the VM has usually only >>> limited write access. >>> >>> Lukas >>> >>> On Wed, Apr 29, 2009 at 10:11 AM, Andy Kellens >>> <[hidden email]> wrote: >>>> >>>> Hello, >>>> >>>> I have a Pier 1.1.1 installation running on our Mac OS X Server. >>>> While the Pier system runs just fine, I noticed that the system >>>> stopped >>>> saving the changes persistently to the image. >>>> After playing around a bit with our installation, I was able to >>>> reproduce >>>> the problem: >>>> - I start with a clean Pier image (and import content from a >>>> previous >>>> 1.1.1 installation using the Importer/Exporter component) >>>> - I choose PRImagePersistency (duration: 30 minutes; >>>> maxImages: 3) >>>> as >>>> the persistency scheme >>>> - I start changing the wiki >>>> - The first two saves work perfectly: Pier creates two new >>>> images + >>>> changes files >>>> - When the third backup should be made, I get an error: >>>> pier.image >>>> not found >>>> - I also tried to manually save the image, but get a >>>> similar error: >>>> Squeak cannot locate the changes file /...../pier.changes. >>>> - I checked: both files are where they should be >>>> >>>> Kind regards, >>>> >>>> Andy >>>> >>>> _______________________________________________ >>>> Magritte, Pier and Related Tools ... >>>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >>>> >>> >>> >>> >>> -- >>> Lukas Renggli >>> http://www.lukas-renggli.ch >>> >>> _______________________________________________ >>> Magritte, Pier and Related Tools ... >>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> >> _______________________________________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
pastedGraphic.tiff (239K)
Re: Persistency problem with Pier 1.1.1 on Mac OS X Server
|
|
Perhaps SqueakDebug.log (it should be where the image is) can give you more information.
Cheers, Mariano On Wed, Apr 29, 2009 at 11:28 AM, Andy Kellens <[hidden email]> wrote: Hi, _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Re: Persistency problem with Pier 1.1.1 on Mac OS X Server
|
|
Hi Andy,
Do you have enough harddisk space? Cheers, Doru On 29 Apr 2009, at 15:48, Mariano Martinez Peck: si, y no es gripe gordito... wrote: > Perhaps SqueakDebug.log (it should be where the image is) can give > you more information. > > Cheers, > > Mariano > > On Wed, Apr 29, 2009 at 11:28 AM, Andy Kellens <[hidden email]> > wrote: > Hi, > > I get a pop-up from squeak (see attached screenshot) and I managed > to see the error, but I can't open up the actual debugger (the pop- > up window just keeps appearing). > I have seen that the old image (pier.image and pier.changes) get > renamed, but apparently the system is not able to create the new > pier.image and pier.changes. > To be sure, I verified that squeak has write privileges to the > correct directory. > > Cheers, > > Andy > > > > On 29 Apr 2009, at 11:10, Lukas Renggli wrote: > > Can you post a full stack trace? > > On Wed, Apr 29, 2009 at 10:39 AM, Andy Kellens <[hidden email]> > wrote: > I checked: the VM has write permissions to the entire .app directory. > > Kind regards, > > Andy > > On 29 Apr 2009, at 10:31, Lukas Renggli wrote: > > We are running several instances on a Mac Server here. > > Are you sure that the VM has write permissions? Especially if you run > the one-click image from /Applications, the VM has usually only > limited write access. > > Lukas > > On Wed, Apr 29, 2009 at 10:11 AM, Andy Kellens <[hidden email]> > wrote: > > Hello, > > I have a Pier 1.1.1 installation running on our Mac OS X Server. > While the Pier system runs just fine, I noticed that the system > stopped > saving the changes persistently to the image. > After playing around a bit with our installation, I was able to > reproduce > the problem: > - I start with a clean Pier image (and import content from a > previous > 1.1.1 installation using the Importer/Exporter component) > - I choose PRImagePersistency (duration: 30 minutes; maxImages: > 3) > as > the persistency scheme > - I start changing the wiki > - The first two saves work perfectly: Pier creates two new > images + > changes files > - When the third backup should be made, I get an error: > pier.image > not found > - I also tried to manually save the image, but get a similar > error: > Squeak cannot locate the changes file /...../pier.changes. > - I checked: both files are where they should be > > Kind regards, > > Andy > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki -- www.tudorgirba.com "Obvious things are difficult to teach." _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Re: Persistency problem with Pier 1.1.1 on Mac OS X Server
|
|
Hello,
Yes, there is plenty of space left on the server. Mariano was right: the stack trace could be found in the debug.log. I added it to the end of this mail. Kind regards, Andy ---- Error: attempt to index non-existent element in an ordered collection 29 April 2009 2:21:15 pm VM: Mac OS - a SmalltalkImage Image: Pharo0.1 [Latest update: #10213] SecurityManager state: Restricted: false FileAccess: true SocketAccess: true Working Dir /Library/WebServer/Wikis/IntensiVE.app/Contents/Resources Trusted Dir /foobar/tooBar/forSqueak/bogus/ Untrusted Dir /foobar/tooBar/forSqueak/bogus/ OrderedCollection(Object)>>error: Receiver: an OrderedCollection('pier_backup_2009-04-28_15-52-46.changes' 'pier_backup_2009-04-28_13-...etc... Arguments and temporary variables: aString: 'attempt to index non-existent element in an ordered collection' Receiver's instance variables: array: #('pier_backup_2009-04-28_15-52-46.changes' 'pier_backup_2009-04-28_13-3...etc... firstIndex: 1 lastIndex: 12 OrderedCollection>>errorNoSuchElement Receiver: an OrderedCollection('pier_backup_2009-04-28_15-52-46.changes' 'pier_backup_2009-04-28_13-...etc... Arguments and temporary variables: Receiver's instance variables: array: #('pier_backup_2009-04-28_15-52-46.changes' 'pier_backup_2009-04-28_13-3...etc... firstIndex: 1 lastIndex: 12 OrderedCollection>>at: Receiver: an OrderedCollection('pier_backup_2009-04-28_15-52-46.changes' 'pier_backup_2009-04-28_13-...etc... Arguments and temporary variables: anInteger: 0 Receiver's instance variables: array: #('pier_backup_2009-04-28_15-52-46.changes' 'pier_backup_2009-04-28_13-3...etc... firstIndex: 1 lastIndex: 12 StandardFileStream class>>readOnlyFileDoesNotExistUserHandling: Receiver: StandardFileStream Arguments and temporary variables: fullFileName: '/Library/WebServer/Wikis/IntensiVE.app/Contents/ Resources/pier.c...etc... dir: UnixFileDirectory on '/Library/WebServer/Wikis/IntensiVE.app/ Contents/Reso...etc... files: #('debug.log' 'pier.icns' 'pier2009-04-29_14-16-40.image' 'pier2009-04-2...etc... choices: an OrderedCollection('pier_backup_2009-04-28_15-52-46.changes' 'pier_b...etc... selection: 0 newName: nil fileName: 'pier.changes' Receiver's instance variables: superclass: FileStream methodDict: a MethodDictionary(#actAsExecutor->a CompiledMethod (98) #ascii->a ...etc... format: 146 instanceVariables: #('name' 'fileID' 'buffer1') organization: ('access' directory directoryUrl file fullName isDirectory localN...etc... subclasses: {CrLfFileStream. MultiByteFileStream} name: #StandardFileStream classPool: a Dictionary(#Registry->a WeakRegistry(<this WeakRegistry is locked>...etc... sharedPools: nil environment: nil category: #'Files-Kernel' traitComposition: nil localSelectors: nil --- The full stack --- OrderedCollection(Object)>>error: OrderedCollection>>errorNoSuchElement OrderedCollection>>at: StandardFileStream class>>readOnlyFileDoesNotExistUserHandling: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - FileDoesNotExistException>>defaultAction UndefinedObject>>handleSignal: MethodContext(ContextPart)>>handleSignal: FileDoesNotExistException(Exception)>>signal MultiByteFileStream class(StandardFileStream class)>>readOnlyFileNamed: MultiByteFileStream(StandardFileStream)>>readOnlyCopy RemoteString>>text CompiledMethod>>getSourceFromFile CompiledMethod>>methodNode Decompiler>>decompileBlock: BlockContext>>decompile BlockContext>>printOn: [] in BlockContext(Object)>>printStringLimitedTo: {[:s | self printOn: s]} String class(SequenceableCollection class)>>streamContents:limitedTo: BlockContext(Object)>>printStringLimitedTo: BlockContext(Object)>>printString [] in OTToolset class>>debug:context:label:contents:fullView: On 29 Apr 2009, at 15:54, Tudor Girba wrote: > Hi Andy, > > Do you have enough harddisk space? > > Cheers, > Doru > > > On 29 Apr 2009, at 15:48, Mariano Martinez Peck: si, y no es gripe > gordito... wrote: > >> Perhaps SqueakDebug.log (it should be where the image is) can give >> you more information. >> >> Cheers, >> >> Mariano >> >> On Wed, Apr 29, 2009 at 11:28 AM, Andy Kellens <[hidden email]> >> wrote: >> Hi, >> >> I get a pop-up from squeak (see attached screenshot) and I managed >> to see the error, but I can't open up the actual debugger (the pop- >> up window just keeps appearing). >> I have seen that the old image (pier.image and pier.changes) get >> renamed, but apparently the system is not able to create the new >> pier.image and pier.changes. >> To be sure, I verified that squeak has write privileges to the >> correct directory. >> >> Cheers, >> >> Andy >> >> >> >> On 29 Apr 2009, at 11:10, Lukas Renggli wrote: >> >> Can you post a full stack trace? >> >> On Wed, Apr 29, 2009 at 10:39 AM, Andy Kellens <[hidden email]> >> wrote: >> I checked: the VM has write permissions to the entire .app directory. >> >> Kind regards, >> >> Andy >> >> On 29 Apr 2009, at 10:31, Lukas Renggli wrote: >> >> We are running several instances on a Mac Server here. >> >> Are you sure that the VM has write permissions? Especially if you run >> the one-click image from /Applications, the VM has usually only >> limited write access. >> >> Lukas >> >> On Wed, Apr 29, 2009 at 10:11 AM, Andy Kellens <[hidden email]> >> wrote: >> >> Hello, >> >> I have a Pier 1.1.1 installation running on our Mac OS X Server. >> While the Pier system runs just fine, I noticed that the system >> stopped >> saving the changes persistently to the image. >> After playing around a bit with our installation, I was able to >> reproduce >> the problem: >> - I start with a clean Pier image (and import content from a >> previous >> 1.1.1 installation using the Importer/Exporter component) >> - I choose PRImagePersistency (duration: 30 minutes; maxImages: >> 3) >> as >> the persistency scheme >> - I start changing the wiki >> - The first two saves work perfectly: Pier creates two new >> images + >> changes files >> - When the third backup should be made, I get an error: >> pier.image >> not found >> - I also tried to manually save the image, but get a similar >> error: >> Squeak cannot locate the changes file /...../pier.changes. >> - I checked: both files are where they should be >> >> Kind regards, >> >> Andy >> >> _______________________________________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> >> >> >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> >> _______________________________________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> >> >> >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> >> >> _______________________________________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> >> _______________________________________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > -- > www.tudorgirba.com > > "Obvious things are difficult to teach." > > > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
|
|
I've attached a ContextPart>>errorReportOn: we use to print more
information, the current one dates from the last decade of the last century and really provides too little data on the instance variables and stack size. For example if we could see all of files: we chould see if the pier.changes file is there. But it looks like it's trying to bring up a debug dialog and failing when it can't find the changes file. In your image preferences have you set it to say there might not be an source or changes file? Also see http://code.google.com/p/pharo/issues/detail?id=512 where saying you don't have an image or changes file still will trigger a walkback if the files *do* exist but you don't have permission to read them. PS I note on an os-x server the file system is case sensitive, on desktop machines it's non-case sensitive. So for example on a desktop machine "IntensiVE.app" and "Intensive.app" would be the same, but on the server it's not. On 29-Apr-09, at 7:06 AM, Andy Kellens wrote: > Hello, > > Yes, there is plenty of space left on the server. > Mariano was right: the stack trace could be found in the debug.log. > I added it to the end of this mail. > > Kind regards, > > Andy > > ---- > > Error: attempt to index non-existent element in an ordered collection > 29 April 2009 2:21:15 pm > > VM: Mac OS - a SmalltalkImage > Image: Pharo0.1 [Latest update: #10213] > > SecurityManager state: > Restricted: false > FileAccess: true > SocketAccess: true > Working Dir /Library/WebServer/Wikis/IntensiVE.app/Contents/Resources > Trusted Dir /foobar/tooBar/forSqueak/bogus/ > Untrusted Dir /foobar/tooBar/forSqueak/bogus/ > > OrderedCollection(Object)>>error: > Receiver: an > OrderedCollection('pier_backup_2009-04-28_15-52-46.changes' > 'pier_backup_2009-04-28_13-...etc... > Arguments and temporary variables: > aString: 'attempt to index non-existent element in an ordered > collection' > Receiver's instance variables: > array: #('pier_backup_2009-04-28_15-52-46.changes' > 'pier_backup_2009-04-28_13-3...etc... > firstIndex: 1 > lastIndex: 12 > > OrderedCollection>>errorNoSuchElement > Receiver: an > OrderedCollection('pier_backup_2009-04-28_15-52-46.changes' > 'pier_backup_2009-04-28_13-...etc... > Arguments and temporary variables: > > Receiver's instance variables: > array: #('pier_backup_2009-04-28_15-52-46.changes' > 'pier_backup_2009-04-28_13-3...etc... > firstIndex: 1 > lastIndex: 12 > > OrderedCollection>>at: > Receiver: an > OrderedCollection('pier_backup_2009-04-28_15-52-46.changes' > 'pier_backup_2009-04-28_13-...etc... > Arguments and temporary variables: > anInteger: 0 > Receiver's instance variables: > array: #('pier_backup_2009-04-28_15-52-46.changes' > 'pier_backup_2009-04-28_13-3...etc... > firstIndex: 1 > lastIndex: 12 > > StandardFileStream class>>readOnlyFileDoesNotExistUserHandling: > Receiver: StandardFileStream > Arguments and temporary variables: > fullFileName: '/Library/WebServer/Wikis/IntensiVE.app/Contents/ > Resources/pier.c...etc... > dir: UnixFileDirectory on '/Library/WebServer/Wikis/IntensiVE.app/ > Contents/Reso...etc... > files: #('debug.log' 'pier.icns' 'pier2009-04-29_14-16-40.image' > 'pier2009-04-2...etc... > choices: an > OrderedCollection('pier_backup_2009-04-28_15-52-46.changes' > 'pier_b...etc... > selection: 0 > newName: nil > fileName: 'pier.changes' > Receiver's instance variables: > superclass: FileStream > methodDict: a MethodDictionary(#actAsExecutor->a CompiledMethod > (98) #ascii->a ...etc... > format: 146 > instanceVariables: #('name' 'fileID' 'buffer1') > organization: ('access' directory directoryUrl file fullName > isDirectory localN...etc... > subclasses: {CrLfFileStream. MultiByteFileStream} > name: #StandardFileStream > classPool: a Dictionary(#Registry->a WeakRegistry(<this > WeakRegistry is locked>...etc... > sharedPools: nil > environment: nil > category: #'Files-Kernel' > traitComposition: nil > localSelectors: nil > > > --- The full stack --- > OrderedCollection(Object)>>error: > OrderedCollection>>errorNoSuchElement > OrderedCollection>>at: > StandardFileStream class>>readOnlyFileDoesNotExistUserHandling: > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > FileDoesNotExistException>>defaultAction > UndefinedObject>>handleSignal: > MethodContext(ContextPart)>>handleSignal: > FileDoesNotExistException(Exception)>>signal > MultiByteFileStream class(StandardFileStream > class)>>readOnlyFileNamed: > MultiByteFileStream(StandardFileStream)>>readOnlyCopy > RemoteString>>text > CompiledMethod>>getSourceFromFile > CompiledMethod>>methodNode > Decompiler>>decompileBlock: > BlockContext>>decompile > BlockContext>>printOn: > [] in BlockContext(Object)>>printStringLimitedTo: {[:s | self > printOn: s]} > String class(SequenceableCollection class)>>streamContents:limitedTo: > BlockContext(Object)>>printStringLimitedTo: > BlockContext(Object)>>printString > [] in OTToolset class>>debug:context:label:contents:fullView: > On 29 Apr 2009, at 15:54, Tudor Girba wrote: > >> Hi Andy, >> >> Do you have enough harddisk space? >> >> Cheers, >> Doru >> >> >> On 29 Apr 2009, at 15:48, Mariano Martinez Peck: si, y no es gripe >> gordito... wrote: >> >>> Perhaps SqueakDebug.log (it should be where the image is) can give >>> you more information. >>> >>> Cheers, >>> >>> Mariano >>> >>> On Wed, Apr 29, 2009 at 11:28 AM, Andy Kellens >>> <[hidden email]> wrote: >>> Hi, >>> >>> I get a pop-up from squeak (see attached screenshot) and I managed >>> to see the error, but I can't open up the actual debugger (the >>> pop-up window just keeps appearing). >>> I have seen that the old image (pier.image and pier.changes) get >>> renamed, but apparently the system is not able to create the new >>> pier.image and pier.changes. >>> To be sure, I verified that squeak has write privileges to the >>> correct directory. >>> >>> Cheers, >>> >>> Andy >>> >>> >>> >>> On 29 Apr 2009, at 11:10, Lukas Renggli wrote: >>> >>> Can you post a full stack trace? >>> >>> On Wed, Apr 29, 2009 at 10:39 AM, Andy Kellens >>> <[hidden email]> wrote: >>> I checked: the VM has write permissions to the entire .app >>> directory. >>> >>> Kind regards, >>> >>> Andy >>> >>> On 29 Apr 2009, at 10:31, Lukas Renggli wrote: >>> >>> We are running several instances on a Mac Server here. >>> >>> Are you sure that the VM has write permissions? Especially if you >>> run >>> the one-click image from /Applications, the VM has usually only >>> limited write access. >>> >>> Lukas >>> >>> On Wed, Apr 29, 2009 at 10:11 AM, Andy Kellens >>> <[hidden email]> wrote: >>> >>> Hello, >>> >>> I have a Pier 1.1.1 installation running on our Mac OS X Server. >>> While the Pier system runs just fine, I noticed that the system >>> stopped >>> saving the changes persistently to the image. >>> After playing around a bit with our installation, I was able to >>> reproduce >>> the problem: >>> - I start with a clean Pier image (and import content from a >>> previous >>> 1.1.1 installation using the Importer/Exporter component) >>> - I choose PRImagePersistency (duration: 30 minutes; maxImages: >>> 3) >>> as >>> the persistency scheme >>> - I start changing the wiki >>> - The first two saves work perfectly: Pier creates two new >>> images + >>> changes files >>> - When the third backup should be made, I get an error: >>> pier.image >>> not found >>> - I also tried to manually save the image, but get a similar >>> error: >>> Squeak cannot locate the changes file /...../pier.changes. >>> - I checked: both files are where they should be >>> >>> Kind regards, >>> >>> Andy >>> ContextPart>>errorReportOn: strm "Write a detailed error report on the stack (above me) on a stream. For both the error file, and emailing a bug report. Suppress any errors while getting printStrings. Limit the length." | cnt aContext startPos | strm print: Date today; space; print: Time now; cr. strm cr. strm nextPutAll: 'VM: '; nextPutAll: SmalltalkImage current platformName asString; nextPutAll: ' - '; nextPutAll: SmalltalkImage current platformSubtype asString; nextPutAll: ' - '; nextPutAll: SmalltalkImage current osVersion asString; nextPutAll: ' - '; nextPutAll: SmalltalkImage current vmVersion asString; cr. strm nextPutAll: 'Image: '; nextPutAll: SystemVersion current version asString; nextPutAll: ' ['; nextPutAll: SmalltalkImage current lastUpdateString asString; nextPutAll: ']'; cr. strm cr. SecurityManager default printStateOn: strm. "Note: The following is an open-coded version of ContextPart>>stackOfSize: since this method may be called during a low space condition and we might run out of space for allocating the full stack." cnt := 0. startPos := strm position. aContext := self. [aContext notNil and: [(cnt := cnt + 1) < 40]] whileTrue: [aContext printDetails: strm. "variable values" strm cr. aContext := aContext sender]. strm cr; nextPutAll: '--- The full stack ---'; cr. aContext := self. cnt := 0. [aContext == nil] whileFalse: [cnt := cnt + 1. cnt = 40 ifTrue: [strm nextPutAll: ' - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -'; cr]. strm print: aContext; cr. "just class>>selector" strm position > (startPos+150000) ifTrue: [strm nextPutAll: '...etc...'. ^ self]. "exit early" cnt > 200 ifTrue: [strm nextPutAll: '-- and more not shown --'. ^ self]. aContext := aContext sender]. _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Re: Persistency problem with Pier 1.1.1 on Mac OS X Server
|
|
In reply to this post by Andy Kellens
Andy - I've seen this error outside of the context of Pier. Once you
get into this state, there is nothing you can do--everything you try to do throws the same error. Whatever the problem turns out to be, it would be really nice to fix it so that the image isn't brought to its knees. David ---- 1 Squeak/Seaside/Pier site deployed On Apr 29, 2009, at 8:06 AM, Andy Kellens wrote: > Hello, > > Yes, there is plenty of space left on the server. > Mariano was right: the stack trace could be found in the debug.log. > I added it to the end of this mail. > > Kind regards, > > Andy > > ---- > > Error: attempt to index non-existent element in an ordered collection > 29 April 2009 2:21:15 pm > > VM: Mac OS - a SmalltalkImage > Image: Pharo0.1 [Latest update: #10213] > > SecurityManager state: > Restricted: false > FileAccess: true > SocketAccess: true > Working Dir /Library/WebServer/Wikis/IntensiVE.app/Contents/Resources > Trusted Dir /foobar/tooBar/forSqueak/bogus/ > Untrusted Dir /foobar/tooBar/forSqueak/bogus/ > > OrderedCollection(Object)>>error: > Receiver: an > OrderedCollection('pier_backup_2009-04-28_15-52-46.changes' > 'pier_backup_2009-04-28_13-...etc... > Arguments and temporary variables: > aString: 'attempt to index non-existent element in an ordered > collection' > Receiver's instance variables: > array: #('pier_backup_2009-04-28_15-52-46.changes' > 'pier_backup_2009-04-28_13-3...etc... > firstIndex: 1 > lastIndex: 12 > > OrderedCollection>>errorNoSuchElement > Receiver: an > OrderedCollection('pier_backup_2009-04-28_15-52-46.changes' > 'pier_backup_2009-04-28_13-...etc... > Arguments and temporary variables: > > Receiver's instance variables: > array: #('pier_backup_2009-04-28_15-52-46.changes' > 'pier_backup_2009-04-28_13-3...etc... > firstIndex: 1 > lastIndex: 12 > > OrderedCollection>>at: > Receiver: an > OrderedCollection('pier_backup_2009-04-28_15-52-46.changes' > 'pier_backup_2009-04-28_13-...etc... > Arguments and temporary variables: > anInteger: 0 > Receiver's instance variables: > array: #('pier_backup_2009-04-28_15-52-46.changes' > 'pier_backup_2009-04-28_13-3...etc... > firstIndex: 1 > lastIndex: 12 > > StandardFileStream class>>readOnlyFileDoesNotExistUserHandling: > Receiver: StandardFileStream > Arguments and temporary variables: > fullFileName: '/Library/WebServer/Wikis/IntensiVE.app/Contents/ > Resources/pier.c...etc... > dir: UnixFileDirectory on '/Library/WebServer/Wikis/IntensiVE.app/ > Contents/Reso...etc... > files: #('debug.log' 'pier.icns' 'pier2009-04-29_14-16-40.image' > 'pier2009-04-2...etc... > choices: an > OrderedCollection('pier_backup_2009-04-28_15-52-46.changes' > 'pier_b...etc... > selection: 0 > newName: nil > fileName: 'pier.changes' > Receiver's instance variables: > superclass: FileStream > methodDict: a MethodDictionary(#actAsExecutor->a CompiledMethod > (98) #ascii->a ...etc... > format: 146 > instanceVariables: #('name' 'fileID' 'buffer1') > organization: ('access' directory directoryUrl file fullName > isDirectory localN...etc... > subclasses: {CrLfFileStream. MultiByteFileStream} > name: #StandardFileStream > classPool: a Dictionary(#Registry->a WeakRegistry(<this > WeakRegistry is locked>...etc... > sharedPools: nil > environment: nil > category: #'Files-Kernel' > traitComposition: nil > localSelectors: nil > > > --- The full stack --- > OrderedCollection(Object)>>error: > OrderedCollection>>errorNoSuchElement > OrderedCollection>>at: > StandardFileStream class>>readOnlyFileDoesNotExistUserHandling: > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > FileDoesNotExistException>>defaultAction > UndefinedObject>>handleSignal: > MethodContext(ContextPart)>>handleSignal: > FileDoesNotExistException(Exception)>>signal > MultiByteFileStream class(StandardFileStream > class)>>readOnlyFileNamed: > MultiByteFileStream(StandardFileStream)>>readOnlyCopy > RemoteString>>text > CompiledMethod>>getSourceFromFile > CompiledMethod>>methodNode > Decompiler>>decompileBlock: > BlockContext>>decompile > BlockContext>>printOn: > [] in BlockContext(Object)>>printStringLimitedTo: {[:s | self > printOn: s]} > String class(SequenceableCollection class)>>streamContents:limitedTo: > BlockContext(Object)>>printStringLimitedTo: > BlockContext(Object)>>printString > [] in OTToolset class>>debug:context:label:contents:fullView: > On 29 Apr 2009, at 15:54, Tudor Girba wrote: > >> Hi Andy, >> >> Do you have enough harddisk space? >> >> Cheers, >> Doru >> >> >> On 29 Apr 2009, at 15:48, Mariano Martinez Peck: si, y no es gripe >> gordito... wrote: >> >>> Perhaps SqueakDebug.log (it should be where the image is) can give >>> you more information. >>> >>> Cheers, >>> >>> Mariano >>> >>> On Wed, Apr 29, 2009 at 11:28 AM, Andy Kellens >>> <[hidden email]> wrote: >>> Hi, >>> >>> I get a pop-up from squeak (see attached screenshot) and I managed >>> to see the error, but I can't open up the actual debugger (the >>> pop-up window just keeps appearing). >>> I have seen that the old image (pier.image and pier.changes) get >>> renamed, but apparently the system is not able to create the new >>> pier.image and pier.changes. >>> To be sure, I verified that squeak has write privileges to the >>> correct directory. >>> >>> Cheers, >>> >>> Andy >>> >>> >>> >>> On 29 Apr 2009, at 11:10, Lukas Renggli wrote: >>> >>> Can you post a full stack trace? >>> >>> On Wed, Apr 29, 2009 at 10:39 AM, Andy Kellens >>> <[hidden email]> wrote: >>> I checked: the VM has write permissions to the entire .app >>> directory. >>> >>> Kind regards, >>> >>> Andy >>> >>> On 29 Apr 2009, at 10:31, Lukas Renggli wrote: >>> >>> We are running several instances on a Mac Server here. >>> >>> Are you sure that the VM has write permissions? Especially if you >>> run >>> the one-click image from /Applications, the VM has usually only >>> limited write access. >>> >>> Lukas >>> >>> On Wed, Apr 29, 2009 at 10:11 AM, Andy Kellens >>> <[hidden email]> wrote: >>> >>> Hello, >>> >>> I have a Pier 1.1.1 installation running on our Mac OS X Server. >>> While the Pier system runs just fine, I noticed that the system >>> stopped >>> saving the changes persistently to the image. >>> After playing around a bit with our installation, I was able to >>> reproduce >>> the problem: >>> - I start with a clean Pier image (and import content from a >>> previous >>> 1.1.1 installation using the Importer/Exporter component) >>> - I choose PRImagePersistency (duration: 30 minutes; maxImages: >>> 3) >>> as >>> the persistency scheme >>> - I start changing the wiki >>> - The first two saves work perfectly: Pier creates two new >>> images + >>> changes files >>> - When the third backup should be made, I get an error: >>> pier.image >>> not found >>> - I also tried to manually save the image, but get a similar >>> error: >>> Squeak cannot locate the changes file /...../pier.changes. >>> - I checked: both files are where they should be >>> >>> Kind regards, >>> >>> Andy >>> >>> _______________________________________________ >>> Magritte, Pier and Related Tools ... >>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >>> >>> >>> >>> >>> -- >>> Lukas Renggli >>> http://www.lukas-renggli.ch >>> >>> _______________________________________________ >>> Magritte, Pier and Related Tools ... >>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >>> >>> _______________________________________________ >>> Magritte, Pier and Related Tools ... >>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >>> >>> >>> >>> >>> -- >>> Lukas Renggli >>> http://www.lukas-renggli.ch >>> >>> _______________________________________________ >>> Magritte, Pier and Related Tools ... >>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >>> >>> >>> _______________________________________________ >>> Magritte, Pier and Related Tools ... >>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >>> >>> _______________________________________________ >>> Magritte, Pier and Related Tools ... >>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> >> -- >> www.tudorgirba.com >> >> "Obvious things are difficult to teach." >> >> >> >> _______________________________________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
«
Return to Magritte, Pier and Related Tools
|
1 view|%1 views
| Free forum by Nabble | Edit this page |