Pharo6 server deployment and no home directory
Hi, as Pharo6 is around the corner I have moved my CI build from tracking Pharo5 to Pharo6 but I run into a problem. Either if $HOME is not set at all or $HOME points to a wrong directory I run into the error below. As this is a server application and I run multiple VMs with the same image and there is no home directory I would prefer that no information is persisted at all. Can this be done? Have there been any changes in Pharo6 in regard to this? It also seems to change from Fuel->Ston for the identifier? Is this intended? holger HOME=/home/blabla ./vm/pharo --nodisplay My.image eval --save '(NonInteractiveTranscript onFileNamed: #stdout)' install PrimitiveFailed: primitive #createDirectory: in UnixStore failed UnixStore(Object)>>primitiveFailed: UnixStore(Object)>>primitiveFailed UnixStore(DiskStore)>>createDirectory: UnixStore(FileSystemStore)>>ensureCreateDirectory: UnixStore(FileSystemStore)>>ensureCreateDirectory: UnixStore(FileSystemStore)>>ensureCreateDirectory: FileSystem>>ensureCreateDirectory: FileReference>>ensureCreateDirectory FileLocator(AbstractFileReference)>>ensureCreateDirectory GlobalIdentifierFuelPersistence(GlobalIdentifierPersistence)>>ensureDirectory GlobalIdentifierFuelPersistence(GlobalIdentifierPersistence)>>save: GlobalIdentifierFuelPersistence(GlobalIdentifierPersistence)>>load: GlobalIdentifierFuelPersistence(GlobalIdentifierPersistence)>>ensure: GlobalIdentifierStonPersistence(GlobalIdentifierPersistence)>>ensure: GlobalIdentifier>>ensure GlobalIdentifier class>>initializeUniqueInstance GlobalIdentifier class>>uniqueInstance SystemSettingsPersistence class>>resumeSystemSettings [ :persistence | persistence resumeSystemSettings ] in PharoCommandLineHandler>>runPreferences in Block: [ :persistence | persistence resumeSystemSettings ...etc... BlockClosure>>cull: SystemDictionary(Dictionary)>>at:ifPresent: SmalltalkImage>>at:ifPresent: PharoCommandLineHandler>>runPreferences PharoCommandLineHandler>>activate PharoCommandLineHandler class(CommandLineHandler class)>>activateWith: [ super activateWith: aCommandLine ] in PharoCommandLineHandler class>>activateWith: in Block: [ super activateWith: aCommandLine ] NonInteractiveUIManager(UIManager)>>defer: PharoCommandLineHandler class>>activateWith: [ aCommandLinehandler activateWith: commandLine ] in BasicCommandLineHandler>>activateSubCommand: in Block: [ aCommandLinehandler activateWith: commandLine ] BlockClosure>>on:do:
Hi,
El 14-04-2017, a las 16:17, Holger Freyther <holger@freyther.de> escribió:
Hi,
as Pharo6 is around the corner I have moved my CI build from tracking Pharo5 to Pharo6 but I run into a problem. Either if $HOME is not set at all or $HOME points to a wrong directory I run into the error below.
As this is a server application and I run multiple VMs with the same image and there is no home directory I would prefer that no information is persisted at all. Can this be done? Have there been any changes in Pharo6 in regard to this?
Do you think that checking if `FileIdentifier home` exist solves the issue? Can we detect headless state?
It also seems to change from Fuel->Ston for the identifier? Is this intended?
Yes, this is intended and should not produce problems. Juraj
holger
HOME=/home/blabla ./vm/pharo --nodisplay My.image eval --save '(NonInteractiveTranscript onFileNamed: #stdout)' install PrimitiveFailed: primitive #createDirectory: in UnixStore failed UnixStore(Object)>>primitiveFailed: UnixStore(Object)>>primitiveFailed UnixStore(DiskStore)>>createDirectory: UnixStore(FileSystemStore)>>ensureCreateDirectory: UnixStore(FileSystemStore)>>ensureCreateDirectory: UnixStore(FileSystemStore)>>ensureCreateDirectory: FileSystem>>ensureCreateDirectory: FileReference>>ensureCreateDirectory FileLocator(AbstractFileReference)>>ensureCreateDirectory GlobalIdentifierFuelPersistence(GlobalIdentifierPersistence)>>ensureDirectory GlobalIdentifierFuelPersistence(GlobalIdentifierPersistence)>>save: GlobalIdentifierFuelPersistence(GlobalIdentifierPersistence)>>load: GlobalIdentifierFuelPersistence(GlobalIdentifierPersistence)>>ensure: GlobalIdentifierStonPersistence(GlobalIdentifierPersistence)>>ensure: GlobalIdentifier>>ensure GlobalIdentifier class>>initializeUniqueInstance GlobalIdentifier class>>uniqueInstance SystemSettingsPersistence class>>resumeSystemSettings [ :persistence | persistence resumeSystemSettings ] in PharoCommandLineHandler>>runPreferences in Block: [ :persistence | persistence resumeSystemSettings ...etc... BlockClosure>>cull: SystemDictionary(Dictionary)>>at:ifPresent: SmalltalkImage>>at:ifPresent: PharoCommandLineHandler>>runPreferences PharoCommandLineHandler>>activate PharoCommandLineHandler class(CommandLineHandler class)>>activateWith: [ super activateWith: aCommandLine ] in PharoCommandLineHandler class>>activateWith: in Block: [ super activateWith: aCommandLine ] NonInteractiveUIManager(UIManager)>>defer: PharoCommandLineHandler class>>activateWith: [ aCommandLinehandler activateWith: commandLine ] in BasicCommandLineHandler>>activateSubCommand: in Block: [ aCommandLinehandler activateWith: commandLine ] BlockClosure>>on:do:
On 15. Apr 2017, at 00:23, Juraj Kubelka <juraj.kubelka@icloud.com> wrote:
Hi,
Hey!
As this is a server application and I run multiple VMs with the same image and there is no home directory I would prefer that no information is persisted at all. Can this be done? Have there been any changes in Pharo6 in regard to this?
Do you think that checking if `FileIdentifier home` exist solves the issue?
Can we detect headless state?
It also seems to change from Fuel->Ston for the identifier? Is this intended?
Yes, this is intended and should not produce problems.
Thank you for your quick reply. What I find odd is that this error seems to be coming from within: GlobalIdentifierStonPersistence(GlobalIdentifierPersistence)>>ensure: self shouldCallPreviousPersistence ifTrue: [ previousPersistence ensure: existingDictionary ]. So there is the "Fuel" Persistence and we want to migrate things. Fair enough but in the migration we do have:
load: existingDictionary "It loads stored information into existingDictionary." self preferences exists ifFalse: [ "This is a new computer, so we define new computer UUID. User still has to agree about sending data if it is not has been done yet." ^ self save: existingDictionary ].
So self preferences exists is true and now the old (non-existent data?) is being saved and we crash and exit on save. * Why isn't the migration from Ston to Fuel more explicit? * Why is "load" trying to save? * Why is "ensure:" used instead of load? * Not sure why "self preferences exists" seems to end in true? have a nice weekend holger
FileLocator(AbstractFileReference)>>ensureCreateDirectory GlobalIdentifierFuelPersistence(GlobalIdentifierPersistence)>>ensureDirectory GlobalIdentifierFuelPersistence(GlobalIdentifierPersistence)>>save: GlobalIdentifierFuelPersistence(GlobalIdentifierPersistence)>>load: GlobalIdentifierFuelPersistence(GlobalIdentifierPersistence)>>ensure: GlobalIdentifierStonPersistence(GlobalIdentifierPersistence)>>ensure: GlobalIdentifier>>ensure
Holger with guille, damien and two students we are looking at how to improve the deployment of pharo and you scenario is really interesting. Stef On Sat, Apr 15, 2017 at 7:59 AM, Holger Freyther <holger@freyther.de> wrote:
On 15. Apr 2017, at 00:23, Juraj Kubelka <juraj.kubelka@icloud.com> wrote:
Hi,
Hey!
As this is a server application and I run multiple VMs with the same image and there is no home directory I would prefer that no information is persisted at all. Can this be done? Have there been any changes in Pharo6 in regard to this?
Do you think that checking if `FileIdentifier home` exist solves the issue?
Can we detect headless state?
It also seems to change from Fuel->Ston for the identifier? Is this
intended?
Yes, this is intended and should not produce problems.
Thank you for your quick reply. What I find odd is that this error seems to be coming from within:
GlobalIdentifierStonPersistence(GlobalIdentifierPersistence)>>ensure: self shouldCallPreviousPersistence ifTrue: [ previousPersistence ensure: existingDictionary ].
So there is the "Fuel" Persistence and we want to migrate things. Fair enough but in the migration we do have:
load: existingDictionary "It loads stored information into existingDictionary." self preferences exists ifFalse: [ "This is a new computer, so we define new computer UUID. User still has to agree about sending data if it is not has been done yet." ^ self save: existingDictionary ].
So self preferences exists is true and now the old (non-existent data?) is being saved and we crash and exit on save.
* Why isn't the migration from Ston to Fuel more explicit? * Why is "load" trying to save? * Why is "ensure:" used instead of load? * Not sure why "self preferences exists" seems to end in true?
have a nice weekend
holger
FileLocator(AbstractFileReference)>>ensureCreateDirectory GlobalIdentifierFuelPersistence(GlobalIdentifierPersistence) ensureDirectory GlobalIdentifierFuelPersistence(GlobalIdentifierPersistence)>>save: GlobalIdentifierFuelPersistence(GlobalIdentifierPersistence)>>load: GlobalIdentifierFuelPersistence(GlobalIdentifierPersistence)>>ensure: GlobalIdentifierStonPersistence(GlobalIdentifierPersistence)>>ensure: GlobalIdentifier>>ensure
On 15. Apr 2017, at 07:59, Holger Freyther <holger@freyther.de> wrote:
* Why isn't the migration from Ston to Fuel more explicit? * Why is "load" trying to save? * Why is "ensure:" used instead of load? * Not sure why "self preferences exists" seems to end in true?
Is there an option to not run startUp options at all or single step through them? I have the suspicion that "exists" returns true while it should not. Will see how to move forward. holger Breakpoint 4, dir_EntryLookup (pathString=0x84cd258 "/home/build/.config/pharo", pathStringLength=25, nameString=0x84ce920 "org.pharo.gt.spotter.event.recorder.fuel", nameStringLength=40, name=0xfffcb1bc "", nameLength=0xfffcb1ac, creationDate=0xfffcb1a4, modificationDate=0xfffcb1b0, isDirectory=0xfffcb1a8, sizeIfFile=0xfffcb198, posixPermissions=0xfffcb1b4, isSymlink=0xfffcb1b8) at /home/travis/build/pharo-project/pharo-vm/opensmalltalk-vm/platforms/unix/plugins/FilePlugin/sqUnixFile.c:270 270 in /home/travis/build/pharo-project/pharo-vm/opensmalltalk-vm/platforms/unix/plugins/FilePlugin/sqUnixFile.c (gdb) p printCallStack() 0xfffd41a0 M UnixStore(DiskStore)>basicEntryAt: 0x842dd28: a(n) UnixStore 0xfffd41c0 M UnixStore(DiskStore)>nodeAt:ifPresent:ifAbsent: 0x842dd28: a(n) UnixStore 0xfffd41e4 M UnixStore(FileSystemStore)>exists: 0x842dd28: a(n) UnixStore 0xfffd4200 M FileSystem>exists: 0x842dd38: a(n) FileSystem 0xfffd421c M FileReference>exists 0x84c9d78: a(n) FileReference 0xfffd4234 M FileLocator(AbstractFileReference)>exists 0x84c32c8: a(n) FileLocator 0xfffd4254 I GlobalIdentifierFuelPersistence(GlobalIdentifierPersistence)>load: 0x84a6d40: a(n) GlobalIdentifierFuelPersistence 0xfffd4278 I GlobalIdentifierFuelPersistence(GlobalIdentifierPersistence)>ensure: 0x84a6d40: a(n) GlobalIdentifierFuelPersistence 0xfffd429c I GlobalIdentifierStonPersistence(GlobalIdentifierPersistence)>ensure: 0x84a6d30: a(n) GlobalIdentifierStonPersistence 0xfffd42c0 I GlobalIdentifier>ensure 0x84a6510: a(n) GlobalIdentifier 0xfffd42e0 I GlobalIdentifier class>initializeUniqueInstance 0x9a2def0: a(n) GlobalIdentifier class 0xfffd4300 I GlobalIdentifier class>uniqueInstance 0x9a2def0: a(n) GlobalIdentifier class 0xfffccfd0 I SystemSettingsPersistence class>resumeSystemSettings 0x9a2d9f0: a(n) SystemSettingsPersistence class
El 15-04-2017, a las 04:11, Holger Freyther <holger@freyther.de> escribió:
On 15. Apr 2017, at 07:59, Holger Freyther <holger@freyther.de> wrote:
* Why isn't the migration from Ston to Fuel more explicit? * Why is "load" trying to save? * Why is "ensure:" used instead of load? * Not sure why "self preferences exists" seems to end in true?
Is there an option to not run startUp options at all or single step through them? I have the suspicion that "exists" returns true while it should not. Will see how to move forward.
Maybe GlobalIdentifier should not write and read anything if --no-preferences option is used. I will check this on Monday. I am without computer now. Juraj
holger
Breakpoint 4, dir_EntryLookup (pathString=0x84cd258 "/home/build/.config/pharo", pathStringLength=25, nameString=0x84ce920 "org.pharo.gt.spotter.event.recorder.fuel", nameStringLength=40, name=0xfffcb1bc "", nameLength=0xfffcb1ac, creationDate=0xfffcb1a4, modificationDate=0xfffcb1b0, isDirectory=0xfffcb1a8, sizeIfFile=0xfffcb198, posixPermissions=0xfffcb1b4, isSymlink=0xfffcb1b8) at /home/travis/build/pharo-project/pharo-vm/opensmalltalk-vm/platforms/unix/plugins/FilePlugin/sqUnixFile.c:270 270 in /home/travis/build/pharo-project/pharo-vm/opensmalltalk-vm/platforms/unix/plugins/FilePlugin/sqUnixFile.c (gdb) p printCallStack() 0xfffd41a0 M UnixStore(DiskStore)>basicEntryAt: 0x842dd28: a(n) UnixStore 0xfffd41c0 M UnixStore(DiskStore)>nodeAt:ifPresent:ifAbsent: 0x842dd28: a(n) UnixStore 0xfffd41e4 M UnixStore(FileSystemStore)>exists: 0x842dd28: a(n) UnixStore 0xfffd4200 M FileSystem>exists: 0x842dd38: a(n) FileSystem 0xfffd421c M FileReference>exists 0x84c9d78: a(n) FileReference 0xfffd4234 M FileLocator(AbstractFileReference)>exists 0x84c32c8: a(n) FileLocator 0xfffd4254 I GlobalIdentifierFuelPersistence(GlobalIdentifierPersistence)>load: 0x84a6d40: a(n) GlobalIdentifierFuelPersistence 0xfffd4278 I GlobalIdentifierFuelPersistence(GlobalIdentifierPersistence)>ensure: 0x84a6d40: a(n) GlobalIdentifierFuelPersistence 0xfffd429c I GlobalIdentifierStonPersistence(GlobalIdentifierPersistence)>ensure: 0x84a6d30: a(n) GlobalIdentifierStonPersistence 0xfffd42c0 I GlobalIdentifier>ensure 0x84a6510: a(n) GlobalIdentifier 0xfffd42e0 I GlobalIdentifier class>initializeUniqueInstance 0x9a2def0: a(n) GlobalIdentifier class 0xfffd4300 I GlobalIdentifier class>uniqueInstance 0x9a2def0: a(n) GlobalIdentifier class 0xfffccfd0 I SystemSettingsPersistence class>resumeSystemSettings 0x9a2d9f0: a(n) SystemSettingsPersistence class
On Sat, Apr 15, 2017 at 3:11 PM, Holger Freyther <holger@freyther.de> wrote:
On 15. Apr 2017, at 07:59, Holger Freyther <holger@freyther.de> wrote:
* Why isn't the migration from Ston to Fuel more explicit? * Why is "load" trying to save? * Why is "ensure:" used instead of load? * Not sure why "self preferences exists" seems to end in true?
Is there an option to not run startUp options at all or single step through them?
Highly speculative...
From the command line compile a "self halt" into PharoCommandLineHandler>>activate
cheers -ben
I have the suspicion that "exists" returns true while it should not. Will see how to move forward.
holger
Breakpoint 4, dir_EntryLookup (pathString=0x84cd258 "/home/build/.config/pharo", pathStringLength=25, nameString=0x84ce920 "org.pharo.gt.spotter.event.recorder.fuel", nameStringLength=40, name=0xfffcb1bc "", nameLength=0xfffcb1ac, creationDate=0xfffcb1a4, modificationDate=0xfffcb1b0, isDirectory=0xfffcb1a8, sizeIfFile=0xfffcb198, posixPermissions=0xfffcb1b4, isSymlink=0xfffcb1b8) at /home/travis/build/pharo-project/pharo-vm/opensmalltalk-vm/platforms/unix/plugins/FilePlugin/sqUnixFile.c:270 270 in /home/travis/build/pharo-project/pharo-vm/opensmalltalk-vm/platforms/unix/plugins/FilePlugin/sqUnixFile.c (gdb) p printCallStack() 0xfffd41a0 M UnixStore(DiskStore)>basicEntryAt: 0x842dd28: a(n) UnixStore 0xfffd41c0 M UnixStore(DiskStore)>nodeAt:ifPresent:ifAbsent: 0x842dd28: a(n) UnixStore 0xfffd41e4 M UnixStore(FileSystemStore)>exists: 0x842dd28: a(n) UnixStore 0xfffd4200 M FileSystem>exists: 0x842dd38: a(n) FileSystem 0xfffd421c M FileReference>exists 0x84c9d78: a(n) FileReference 0xfffd4234 M FileLocator(AbstractFileReference)>exists 0x84c32c8: a(n) FileLocator 0xfffd4254 I GlobalIdentifierFuelPersistence(GlobalIdentifierPersistence)>load: 0x84a6d40: a(n) GlobalIdentifierFuelPersistence 0xfffd4278 I GlobalIdentifierFuelPersistence(GlobalIdentifierPersistence)>ensure: 0x84a6d40: a(n) GlobalIdentifierFuelPersistence 0xfffd429c I GlobalIdentifierStonPersistence(GlobalIdentifierPersistence)>ensure: 0x84a6d30: a(n) GlobalIdentifierStonPersistence 0xfffd42c0 I GlobalIdentifier>ensure 0x84a6510: a(n) GlobalIdentifier 0xfffd42e0 I GlobalIdentifier class>initializeUniqueInstance 0x9a2def0: a(n) GlobalIdentifier class 0xfffd4300 I GlobalIdentifier class>uniqueInstance 0x9a2def0: a(n) GlobalIdentifier class 0xfffccfd0 I SystemSettingsPersistence class>resumeSystemSettings 0x9a2d9f0: a(n) SystemSettingsPersistence class
Hi Holger, I have resolved the issue: https://pharo.fogbugz.com/f/cases/19944/Server-deployment-is-broken-due-to-G... <https://pharo.fogbugz.com/f/cases/19944/Server-deployment-is-broken-due-to-G...> I will appreciate if you review it and test it. Basically it tests `FileLocator home exists`, if false, it does not touch disk. We could also add a #disablePersistence method if necessary. Juraj
On Apr 15, 2017, at 04:11, Holger Freyther <holger@freyther.de> wrote:
On 15. Apr 2017, at 07:59, Holger Freyther <holger@freyther.de> wrote:
* Why isn't the migration from Ston to Fuel more explicit? * Why is "load" trying to save? * Why is "ensure:" used instead of load? * Not sure why "self preferences exists" seems to end in true?
Is there an option to not run startUp options at all or single step through them? I have the suspicion that "exists" returns true while it should not. Will see how to move forward.
holger
Breakpoint 4, dir_EntryLookup (pathString=0x84cd258 "/home/build/.config/pharo", pathStringLength=25, nameString=0x84ce920 "org.pharo.gt.spotter.event.recorder.fuel", nameStringLength=40, name=0xfffcb1bc "", nameLength=0xfffcb1ac, creationDate=0xfffcb1a4, modificationDate=0xfffcb1b0, isDirectory=0xfffcb1a8, sizeIfFile=0xfffcb198, posixPermissions=0xfffcb1b4, isSymlink=0xfffcb1b8) at /home/travis/build/pharo-project/pharo-vm/opensmalltalk-vm/platforms/unix/plugins/FilePlugin/sqUnixFile.c:270 270 in /home/travis/build/pharo-project/pharo-vm/opensmalltalk-vm/platforms/unix/plugins/FilePlugin/sqUnixFile.c (gdb) p printCallStack() 0xfffd41a0 M UnixStore(DiskStore)>basicEntryAt: 0x842dd28: a(n) UnixStore 0xfffd41c0 M UnixStore(DiskStore)>nodeAt:ifPresent:ifAbsent: 0x842dd28: a(n) UnixStore 0xfffd41e4 M UnixStore(FileSystemStore)>exists: 0x842dd28: a(n) UnixStore 0xfffd4200 M FileSystem>exists: 0x842dd38: a(n) FileSystem 0xfffd421c M FileReference>exists 0x84c9d78: a(n) FileReference 0xfffd4234 M FileLocator(AbstractFileReference)>exists 0x84c32c8: a(n) FileLocator 0xfffd4254 I GlobalIdentifierFuelPersistence(GlobalIdentifierPersistence)>load: 0x84a6d40: a(n) GlobalIdentifierFuelPersistence 0xfffd4278 I GlobalIdentifierFuelPersistence(GlobalIdentifierPersistence)>ensure: 0x84a6d40: a(n) GlobalIdentifierFuelPersistence 0xfffd429c I GlobalIdentifierStonPersistence(GlobalIdentifierPersistence)>ensure: 0x84a6d30: a(n) GlobalIdentifierStonPersistence 0xfffd42c0 I GlobalIdentifier>ensure 0x84a6510: a(n) GlobalIdentifier 0xfffd42e0 I GlobalIdentifier class>initializeUniqueInstance 0x9a2def0: a(n) GlobalIdentifier class 0xfffd4300 I GlobalIdentifier class>uniqueInstance 0x9a2def0: a(n) GlobalIdentifier class 0xfffccfd0 I SystemSettingsPersistence class>resumeSystemSettings 0x9a2d9f0: a(n) SystemSettingsPersistence class
On 17. Apr 2017, at 21:30, Juraj Kubelka <juraj.kubelka@icloud.com> wrote:
Hi Holger,
Hey Juraj!
Basically it tests `FileLocator home exists`, if false, it does not touch disk. We could also add a #disablePersistence method if necessary.
I thought I tested it but somehow it is broken (again)? Looks like FileLocator>>#exists fails instead of answering false? Can you reproduce it? $ unset HOME $ pharo ... Error: Can't find the requested origin UnixResolver(PlatformResolver)>>cantFindOriginError [ self cantFindOriginError ] in UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed: in Block: [ self cantFindOriginError ] UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or: UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed: UnixResolver>>home [ self home / '.config' ] in UnixResolver>>preferences in Block: [ self home / '.config' ] UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or: UnixResolver>>preferences UnixResolver(FileSystemResolver)>>resolve: SystemResolver(FileSystemResolver)>>unknownOrigin: SystemResolver(FileSystemResolver)>>resolve: InteractiveResolver>>unknownOrigin: [ self unknownOrigin: origin ] in InteractiveResolver>>resolve: in Block: [ self unknownOrigin: origin ] IdentityDictionary(Dictionary)>>at:ifAbsent: InteractiveResolver>>resolve: FileLocator>>resolve FileLocator(AbstractFileReference)>>exists GlobalIdentifierStonPersistence(GlobalIdentifierPersistence)>>shouldCallPreviousPersistence GlobalIdentifierStonPersistence(GlobalIdentifierPersistence)>>ensure: GlobalIdentifier>>ensure GlobalIdentifier class>>initializeUniqueInstance GlobalIdentifier class>>uniqueInstance SystemSettingsPersistence class>>resumeSystemSettings [ :persistence | persistence resumeSystemSettings ] in PharoCommandLineHandler>>runPreferences in Block: [ :persistence | persistence resumeSystemSettings ...etc... BlockClosure>>cull: SystemDictionary(Dictionary)>>at:ifPresent: SmalltalkImage>>at:ifPresent: PharoCommandLineHandler>>runPreferences PharoCommandLineHandler>>activate PharoCommandLineHandler class(CommandLineHandler class)>>activateWith:
On 8. Jun 2017, at 23:16, Holger Freyther <holger@freyther.de> wrote:
Hey Juraj!
Hey! this will most likely block more people trying to deploy a headless Pharo6 image but I am not so sure how to properly fix it.
$ unset HOME $ pharo ... Error: Can't find the requested origin ...
UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:
$HOME is not set so cantFindOriginError will be executed.
UnixResolver>>home [ self home / '.config' ] in UnixResolver>>preferences in Block: [ self home / '.config' ]
XDG_CONFIG_DIR can not be found and then "self home" will be executed...
FileLocator(AbstractFileReference)>>exists
(FileLocator preferences / '.config' / ...) resolve exists a.) Behave like unix and resolve $HOME to '' $ unset HOME $ echo $HOME/.config /.config self home / '.config' => '/.config' b.) FileLocator>>#exists If something can not be resolved, one can argue that it doesn't exist? So I wonder if the exception should be catched and false be returned? c.) ??? I don't see an obvious/good approach. Do you? holger
On 9. Jun 2017, at 11:09, Holger Freyther <holger@freyther.de> wrote:
a.) Behave like unix and resolve $HOME to ''
$ unset HOME $ echo $HOME/.config /.config
self home / '.config' => '/.config'
Implementing UnixResolver>>#home as home ^ self directoryFromEnvVariableNamed: 'HOME' or: [self resolveString: ''] will lead to something creating /.config/pharo (if possible). By itself this change is not good enough but when adding --no-default-preferences. Comments? Opinions? holger
Why would $HOME not be set ? And if it is not set / seems like a reasonable default.
On 9 Jun 2017, at 06:06, Holger Freyther <holger@freyther.de> wrote:
On 9. Jun 2017, at 11:09, Holger Freyther <holger@freyther.de> wrote:
a.) Behave like unix and resolve $HOME to ''
$ unset HOME $ echo $HOME/.config /.config
self home / '.config' => '/.config'
Implementing UnixResolver>>#home as
home ^ self directoryFromEnvVariableNamed: 'HOME' or: [self resolveString: '']
will lead to something creating /.config/pharo (if possible). By itself this change is not good enough but when adding --no-default-preferences.
Comments? Opinions?
holger
On 9. Jun 2017, at 13:26, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hey,
Why would $HOME not be set ?
In this specific case runit doesn't export HOME when starting my service but looking at systemd and picking a random service like exim4.service I see: $ strings /proc/946/environ PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin LANG=C _SYSTEMCTL_SKIP_REDIRECT=true PWD=/ I think it is safe to assume this applies to other services started by systemd as well.
And if it is not set / seems like a reasonable default.
In Shell it would be "" but with >>resolveString: '' it seems to be / but that seems to be fair enough. E.g. as {home} / '.config' is used anyway. holger
Hi Holger, thanks for the report. I will resolve it soon: https://pharo.fogbugz.com/f/cases/20135/Server-deployment-is-broken-due-to-G... <https://pharo.fogbugz.com/f/cases/20135/Server-deployment-is-broken-due-to-G...> Cheers, Juraj
El 08-06-2017, a las 17:16, Holger Freyther <holger@freyther.de> escribió:
On 17. Apr 2017, at 21:30, Juraj Kubelka <juraj.kubelka@icloud.com> wrote:
Hi Holger,
Hey Juraj!
Basically it tests `FileLocator home exists`, if false, it does not touch disk. We could also add a #disablePersistence method if necessary.
I thought I tested it but somehow it is broken (again)? Looks like FileLocator>>#exists fails instead of answering false? Can you reproduce it?
$ unset HOME $ pharo ... Error: Can't find the requested origin UnixResolver(PlatformResolver)>>cantFindOriginError [ self cantFindOriginError ] in UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed: in Block: [ self cantFindOriginError ] UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or: UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed: UnixResolver>>home [ self home / '.config' ] in UnixResolver>>preferences in Block: [ self home / '.config' ] UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or: UnixResolver>>preferences UnixResolver(FileSystemResolver)>>resolve: SystemResolver(FileSystemResolver)>>unknownOrigin: SystemResolver(FileSystemResolver)>>resolve: InteractiveResolver>>unknownOrigin: [ self unknownOrigin: origin ] in InteractiveResolver>>resolve: in Block: [ self unknownOrigin: origin ] IdentityDictionary(Dictionary)>>at:ifAbsent: InteractiveResolver>>resolve: FileLocator>>resolve FileLocator(AbstractFileReference)>>exists GlobalIdentifierStonPersistence(GlobalIdentifierPersistence)>>shouldCallPreviousPersistence GlobalIdentifierStonPersistence(GlobalIdentifierPersistence)>>ensure: GlobalIdentifier>>ensure GlobalIdentifier class>>initializeUniqueInstance GlobalIdentifier class>>uniqueInstance SystemSettingsPersistence class>>resumeSystemSettings [ :persistence | persistence resumeSystemSettings ] in PharoCommandLineHandler>>runPreferences in Block: [ :persistence | persistence resumeSystemSettings ...etc... BlockClosure>>cull: SystemDictionary(Dictionary)>>at:ifPresent: SmalltalkImage>>at:ifPresent: PharoCommandLineHandler>>runPreferences PharoCommandLineHandler>>activate PharoCommandLineHandler class(CommandLineHandler class)>>activateWith:
Hi Holger, I have an impression that it can be solved by using "--no-default-preferencesâ option: ./pharo Pharo.image --no-default-preferences Is it a good solution for you? Or do you need to load some preferences? Another option could be implementing an error signal, e.g., CantFindOriginError in the cantFindOriginError method and catch this in the GlobalIdentifier object. Cheers, Juraj
El 11-06-2017, a las 11:36, Juraj Kubelka <juraj.kubelka@icloud.com> escribió:
Hi Holger,
thanks for the report. I will resolve it soon: https://pharo.fogbugz.com/f/cases/20135/Server-deployment-is-broken-due-to-G... <https://pharo.fogbugz.com/f/cases/20135/Server-deployment-is-broken-due-to-G...>
Cheers, Juraj
El 08-06-2017, a las 17:16, Holger Freyther <holger@freyther.de <mailto:holger@freyther.de>> escribió:
On 17. Apr 2017, at 21:30, Juraj Kubelka <juraj.kubelka@icloud.com <mailto:juraj.kubelka@icloud.com>> wrote:
Hi Holger,
Hey Juraj!
Basically it tests `FileLocator home exists`, if false, it does not touch disk. We could also add a #disablePersistence method if necessary.
I thought I tested it but somehow it is broken (again)? Looks like FileLocator>>#exists fails instead of answering false? Can you reproduce it?
$ unset HOME $ pharo ... Error: Can't find the requested origin UnixResolver(PlatformResolver)>>cantFindOriginError [ self cantFindOriginError ] in UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed: in Block: [ self cantFindOriginError ] UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or: UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed: UnixResolver>>home [ self home / '.config' ] in UnixResolver>>preferences in Block: [ self home / '.config' ] UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or: UnixResolver>>preferences UnixResolver(FileSystemResolver)>>resolve: SystemResolver(FileSystemResolver)>>unknownOrigin: SystemResolver(FileSystemResolver)>>resolve: InteractiveResolver>>unknownOrigin: [ self unknownOrigin: origin ] in InteractiveResolver>>resolve: in Block: [ self unknownOrigin: origin ] IdentityDictionary(Dictionary)>>at:ifAbsent: InteractiveResolver>>resolve: FileLocator>>resolve FileLocator(AbstractFileReference)>>exists GlobalIdentifierStonPersistence(GlobalIdentifierPersistence)>>shouldCallPreviousPersistence GlobalIdentifierStonPersistence(GlobalIdentifierPersistence)>>ensure: GlobalIdentifier>>ensure GlobalIdentifier class>>initializeUniqueInstance GlobalIdentifier class>>uniqueInstance SystemSettingsPersistence class>>resumeSystemSettings [ :persistence | persistence resumeSystemSettings ] in PharoCommandLineHandler>>runPreferences in Block: [ :persistence | persistence resumeSystemSettings ...etc... BlockClosure>>cull: SystemDictionary(Dictionary)>>at:ifPresent: SmalltalkImage>>at:ifPresent: PharoCommandLineHandler>>runPreferences PharoCommandLineHandler>>activate PharoCommandLineHandler class(CommandLineHandler class)>>activateWith:
On 12. Jun 2017, at 16:41, Juraj Kubelka <juraj.kubelka@icloud.com> wrote:
Hi Holger,
I have an impression that it can be solved by using "--no-default-preferencesâ option: ./pharo Pharo.image --no-default-preferences
Is it a good solution for you? Or do you need to load some preferences?
Right, unsetting HOME and then using --no-default-preferences makes the error go away.
Another option could be implementing an error signal, e.g., CantFindOriginError in the cantFindOriginError method and catch this in the GlobalIdentifier object.
I wonder if "FileLocator home exists" should really throw an exception in case {home} can not be resolved. a.) Just because it can not be resolved, it might still exist? b.) If it can not be resolved it doesn't exist from an image point of view? holger
El 16-06-2017, a las 10:34, Holger Freyther <holger@freyther.de> escribió:
On 12. Jun 2017, at 16:41, Juraj Kubelka <juraj.kubelka@icloud.com> wrote:
Hi Holger,
I have an impression that it can be solved by using "--no-default-preferencesâ option: ./pharo Pharo.image --no-default-preferences
Is it a good solution for you? Or do you need to load some preferences?
Right, unsetting HOME and then using --no-default-preferences makes the error go away.
Another option could be implementing an error signal, e.g., CantFindOriginError in the cantFindOriginError method and catch this in the GlobalIdentifier object.
I wonder if "FileLocator home exists" should really throw an exception in case {home} can not be resolved.
a.) Just because it can not be resolved, it might still exist? b.) If it can not be resolved it doesn't exist from an image point of view?
I think it is better to throw an exception. Then someone is sure that does not use a code, that needs {home} directory, but cannot. Maybe there could be a specialized error class for this. Now it uses Error, if I remember well. Juraj
holger
participants (5)
-
Ben Coman -
Holger Freyther -
Juraj Kubelka -
Stephane Ducasse -
Sven Van Caekenberghe