Thread: Problem with the 9.1 one-click installer Windows7 64bit
Hi, I tried to install 9.1 on a Windows7 64bit machine but the installation hangs during the initdb process. Looking at the taskmanager I could see that the installer script was waiting for icacls.exe to complete setting the approriatepermissions on the data directory. As I know that problems during initdb are usually a sign of some permission problems, I pre-created the data directory andmanually changed the owner of that directory to be the one of the postgres service account (which is a *local* user, nota domain user) With the second attempt, the installer again hang during initdb. Checking the state using ProcessExplorer I could see thatthe installer script was waiting for icacls.exe to set permissions for the user currently running the installer. It wasrunning [icacls.exe "thomas"] instead of [icacls.exe "mydomain\thomas"] - although I have to admit that I don't know ifthat would make a difference. So I killed the iacls.exe and the script proceeded, just to hang at the next call to icacls.exe when it tried to set theprivileges on the directory for the postgres user despite the fact that that user already was the owner and had full controlover it. So I killed icacls.exe again and then the script finally finished without problems. The service was registeredand successully started. UAC is turned off on my computer. Btw: is there a way to run the one-click installer *without* the automatically running initdb? I did not have these problems on the same computer with the 9.0 installer - the only difference is that I installed the 32bitversion of 9.0, while I know decided to use the 64bit version. Could that make a difference? Regards Thomas
On Mon, Sep 12, 2011 at 10:12 AM, Thomas Kellerer <spam_eater@gmx.net> wrote: > Hi, > > I tried to install 9.1 on a Windows7 64bit machine but the installation > hangs during the initdb process. > > Looking at the taskmanager I could see that the installer script was waiting > for icacls.exe to complete setting the approriate permissions on the data > directory. > > As I know that problems during initdb are usually a sign of some permission > problems, I pre-created the data directory and manually changed the owner of > that directory to be the one of the postgres service account (which is a > *local* user, not a domain user) > > With the second attempt, the installer again hang during initdb. Checking > the state using ProcessExplorer I could see that the installer script was > waiting for icacls.exe to set permissions for the user currently running the > installer. It was running [icacls.exe "thomas"] instead of [icacls.exe > "mydomain\thomas"] - although I have to admit that I don't know if that > would make a difference. > > So I killed the iacls.exe and the script proceeded, just to hang at the next > call to icacls.exe when it tried to set the privileges on the directory for > the postgres user despite the fact that that user already was the owner and > had full control over it. So I killed icacls.exe again and then the script > finally finished without problems. The service was registered and > successully started. > > UAC is turned off on my computer. > > Btw: is there a way to run the one-click installer *without* the > automatically running initdb? > > I did not have these problems on the same computer with the 9.0 installer - > the only difference is that I installed the 32bit version of 9.0, while I > know decided to use the 64bit version. Could that make a difference? hm, why is icacls hanging? does it do that if you run it from the command line? merlin
Merlin Moncure, 12.09.2011 21:28:
>> With the second attempt, the installer again hang during initdb. Checking
>> the state using ProcessExplorer I could see that the installer script was
>> waiting for icacls.exe to set permissions for the user currently running the
>> installer. It was running [icacls.exe "thomas"] instead of [icacls.exe
>> "mydomain\thomas"] - although I have to admit that I don't know if that
>> would make a difference.
>>
>> So I killed the iacls.exe and the script proceeded, just to hang at the next
>> call to icacls.exe when it tried to set the privileges on the directory for
>> the postgres user despite the fact that that user already was the owner and
>> had full control over it. So I killed icacls.exe again and then the script
>> finally finished without problems. The service was registered and
>> successully started.
>>
>> UAC is turned off on my computer.
>>
>
> hm, why is icacls hanging? does it do that if you run it from the command line?
>
I re-ran the installer and copied the actual commandline the installer was using.
It turned out that it tries the following:
(Note that the selected data directory is c:\Daten\db\pgdata91)
icacls C:\ /grant "tkellerer":RX
(Changing the permission for the whole harddisk!!)
Then when I kill that process, the installer starts a new one with
icacls "C:\Daten" /grant "tkellerer":RX
Then I kill that one again, a new one is started with:
icacls C:\ /grant "postgres":RX
Then after killing that one, a new one is started with:
icacls "C:\Daten" /grant "postgres":RX
So it didn't actually hang, but changing the permissions for the entire harddisk (170GB taken) and the complete
c:\Daten(~20GB) directory twice would have taken ages.
Seems there is something fishy about the way the iacls.exe commandline is assembled.
Regards
Thomas
On 09/13/2011 02:44 PM, Thomas Kellerer wrote: > It turned out that it tries the following: > (Note that the selected data directory is c:\Daten\db\pgdata91) > > icacls C:\ /grant "tkellerer":RX > > (Changing the permission for the whole harddisk!!) I forwarded your message to Dave Page in case the EDB folks needed to look into this. He commented that: "Aside from the fact that icacls is hanging for reasons unknown, it appears to be doing what it is designed to do - it traverses up the path from the data directory to the root directory, granting read/execute permissions on each dir as it goes. It's a non-recursive grant (the default - /T makes it recurse), and is done because a great deal of the failures we used to see were caused by the user not having read or execute permissions on one of the parents of the data directory (or installation directory)." ... which to me explains why: > Then when I kill that process, the installer starts a new one with > > icacls "C:\Daten" /grant "tkellerer":RX > So it didn't actually hang, but changing the permissions for the entire > harddisk (170GB taken) and the complete c:\Daten (~20GB) directory twice > would have taken ages. As Dave noted, it's a non-recursive grant. It isn't changing the permissions for C:\ and everything under it. It's only changing the permissions for C:\ its self. It's then stepping down the path of parents down to the datadir and doing the same thing to make sure you have the required rights on every folder all the way down. See: http://technet.microsoft.com/en-us/library/cc753525(WS.10).aspx and note the lack of the /t flag when icacls is called. Given that, it's not clear why it's taking so long. A lock of some kind, maybe? Anyway, it's *not* recursively changing the permissions on your HDD. -- Craig Ringer
Craig Ringer, 14.09.2011 06:20: > I forwarded your message to Dave Page in case the EDB folks needed to > look into this. He commented that: > > "Aside from the fact that icacls is hanging for reasons unknown, it > appears to be doing what it is designed to do - it traverses up the > path from the data directory to the root directory, granting > read/execute permissions on each dir as it goes. It's a non-recursive > grant (the default - /T makes it recurse), and is done because a > great deal of the failures we used to see were caused by the user not > having read or execute permissions on one of the parents of the data > directory (or installation directory)." > > ... which to me explains why: > >> Then when I kill that process, the installer starts a new one with >> >> icacls "C:\Daten" /grant "tkellerer":RX > > As Dave noted, it's a non-recursive grant. It isn't changing the > permissions for C:\ and everything under it. It's only changing the > permissions for C:\ its self. It's then stepping down the path of > parents down to the datadir and doing the same thing to make sure you > have the required rights on every folder all the way down. > > See: http://technet.microsoft.com/en-us/library/cc753525(WS.10).aspx > > and note the lack of the /t flag when icacls is called. > > Given that, it's not clear why it's taking so long. A lock of some > kind, maybe? Anyway, it's *not* recursively changing the permissions > on your HDD. Thanks for the feedback. Those steps do make sense - and I appreciate the installer doing that, as there were a lot of problems in various forumsregarding the permissions ;) But I have no idea why it's hanging (or taking that long). I ran the installer on a Windows XP box (32bit) that is not part of a domain, and there everything worked just fine. I currently don't have time to re-test this and wait until it finished (or check what iacls.exe is waiting for). But maybenext week I can try to find the real reason for that. Regards Thomas
Thomas Kellerer wrote: > So I killed the iacls.exe and the script proceeded, just to hang at > the next call to icacls.exe when it tried to set the privileges on the > directory for the postgres user despite the fact that that user > already was the owner and had full control over it. So I killed > icacls.exe again and then the script finally finished without > problems. The service was registered and successully started. Before killing hanging processes that I can't explain I usually go out and get myself a coffee. In this particular case it fixed the problem because iacls.exe didn't actually hang but only took some time to complete. Regards, Brar
Brar Piening, 14.09.2011 21:49: > Thomas Kellerer wrote: >> So I killed the iacls.exe and the script proceeded, just to hang at >> the next call to icacls.exe when it tried to set the privileges on >> the directory for the postgres user despite the fact that that user >> already was the owner and had full control over it. So I killed >> icacls.exe again and then the script finally finished without >> problems. The service was registered and successully started. > > Before killing hanging processes that I can't explain I usually go > out and get myself a coffee. In this particular case it fixed the > problem because iacls.exe didn't actually hang but only took some > time to complete. > I'm reluctant to killing processes as well. I waited for about 10 minutes before I gave up.... Regards Thomas
Craig Ringer, 14.09.2011 06:20: > As Dave noted, it's a non-recursive grant. It isn't changing the > permissions for C:\ and everything under it. It's only changing the > permissions for C:\ its self. It's then stepping down the path of > parents down to the datadir and doing the same thing to make sure you > have the required rights on every folder all the way down. > > See: http://technet.microsoft.com/en-us/library/cc753525(WS.10).aspx > > and note the lack of the /t flag when icacls is called. I ran another install and monitored what the process was doing and it *is* recursively touching all files on my harddiskwhen icacls C:\ /grant "tkellerer":RX is called. Even without the /t switch. I verified this using ProcessExplorer displaying the open file handles for the running icacls.exe So there is either some (hidden?) system setting that makes icacls to recurse by default or something has changed in Windows7. I can see the exact same behaviour (touching all files recursively) when I run the above command manually from a commandprompt Regards Thomas
On 15/09/2011 4:18 PM, Thomas Kellerer wrote: > I ran another install and monitored what the process was doing and it > *is* recursively touching all files on my harddisk when > > icacls C:\ /grant "tkellerer":RX > > is called. Even without the /t switch. That's a worry. > > I verified this using ProcessExplorer displaying the open file handles > for the running icacls.exe It'd be interesting to generate a Process Monitor trace for this, as it'll show exactly what iacls is doing. Just having a handle open to some random file is weird, but it'd be good to know if it's messing with permissions too. I wonder if it's to do with ACL inheritance? Maybe one of the inheritance control flags like "NP" is needed. I don't know enough about NT permissions to say, but inheritance would be my suspect. -- Craig Ringer
Craig Ringer, 16.09.2011 05:02: > On 15/09/2011 4:18 PM, Thomas Kellerer wrote: >> I ran another install and monitored what the process was doing and >> it *is* recursively touching all files on my harddisk when >> >> icacls C:\ /grant "tkellerer":RX >> >> is called. Even without the /t switch. > > That's a worry. > > It'd be interesting to generate a Process Monitor trace for this, as > it'll show exactly what iacls is doing. Just having a handle open to > some random file is weird, but it'd be good to know if it's messing > with permissions too. I have created such a trace file which is quite large, so I removed a lot of repetitions where each and every file that wasprocessed was shown. I hope it still contains enough information for you to find out what is going on. I have uploaded the file here: http://www.sql-workbench.net/icacls_trace.zip As this works correctly on XP I'm wondering if there is a substantial difference between cacls.exe (which is used on XP bythe installer script) and the new icacls.exe > I wonder if it's to do with ACL inheritance? Maybe one of the > inheritance control flags like "NP" is needed. I don't know enough > about NT permissions to say, but inheritance would be my suspect. No, idea either. I am by no means a Windows expert. Regards Thomas
the process explorer was the big help for me. what i did while the installation was running was open up process explorer saw what it was running and obviously figured out what it was trying to do and i just went and manually did it myself then i'd kill the icalc.exe...after that another one popped up and i did it again the first time was for the user i was logged in as...the second was for the postgres user...after i set the permissions manually i killed the other icalcs.exe and then it continued to initdb... hope this helps -- View this message in context: http://postgresql.1045698.n5.nabble.com/Problem-with-the-9-1-one-click-installer-Windows7-64bit-tp4794537p4845892.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.