Обсуждение: PgAdmin4 STILL not usable when installed from RPMs on Fedora linux
Dear PgAdmin4 maintainers,
I've installed the latest pgadmin4-v1 package from the PGDG repository.
Unfortunately, it still does not work.
Now (as oppossed to the previous version of the package) there is a
pgadmin4 binary in the path, starting it results in the familiar "An
error occurred initialising the application server: Failed to locate
pgAdmin4.py, terminating server thread." message box and (usually) a
segmentation fault.
The reason for this is that the application does not know where to find
the python server backend. On my machine, it tries the following
locations:
stat("/home/pjuhasz/.config/pgAdmin Development Team/pgAdmin 4.conf", 0x7ffcb842f9b0) = -1 ENOENT (No such file or
directory)
stat("/home/pjuhasz/.config/pgAdmin Development Team/pgAdmin 4.conf", 0x7ffcb842f9b0) = -1 ENOENT (No such file or
directory)
stat("/home/pjuhasz/.config/pgAdmin Development Team/pgAdmin 4.conf", 0x7ffcb842f990) = -1 ENOENT (No such file or
directory)
stat("/home/pjuhasz/.config/pgAdmin Development Team.conf", 0x7ffcb842f9b0) = -1 ENOENT (No such file or directory)
stat("/home/pjuhasz/.config/pgAdmin Development Team.conf", 0x7ffcb842f9b0) = -1 ENOENT (No such file or directory)
stat("/home/pjuhasz/.config/pgAdmin Development Team.conf", 0x7ffcb842f990) = -1 ENOENT (No such file or directory)
stat("/etc/xdg/pgAdmin Development Team/pgAdmin 4.conf", 0x7ffcb842f9b0) = -1 ENOENT (No such file or directory)
stat("/etc/xdg/pgAdmin Development Team/pgAdmin 4.conf", 0x7ffcb842f9b0) = -1 ENOENT (No such file or directory)
stat("/etc/xdg/pgAdmin Development Team/pgAdmin 4.conf", 0x7ffcb842f990) = -1 ENOENT (No such file or directory)
stat("/etc/xdg/pgAdmin Development Team.conf", 0x7ffcb842f9b0) = -1 ENOENT (No such file or directory)
stat("/etc/xdg/pgAdmin Development Team.conf", 0x7ffcb842f9b0) = -1 ENOENT (No such file or directory)
stat("/etc/xdg/pgAdmin Development Team.conf", 0x7ffcb842f990) = -1 ENOENT (No such file or directory)
Not knowing the correct path it tries /usr/pgadmin4-
v1/runtime/pgAdmin4.py and even /pgAdmin4.py, then eventually gives up.
The package installs a pgadmin4.ini next to the pgAdmin4 binary,
containing the correct path, but this file is never accessed.
The reason for this is that QSettings is used in the pgadmin4 program
with default settings, which causes Qt to try the locations mentioned
above. This behavior is documented at e.g. http://doc.qt.io/archives/qt
-4.7/qsettings.html#platform-specific-notes .
Something is still wrong, though, because the application does not
start even after manually copying the provided pgadmin4.ini to one of
the previously mentioned locations.
I'd also like to mention that directory names with spaces and capital
letters are discouraged (to put it lightly) in Linux.
I can access the webapp from a browser after running "systemctl start
pgadmin4-v1.service", but
- this is not documented (AFAIK),
- this is not something I want to do,
- for users that don't have root permissions this might not be an
option.
Best regards,
Peter Juhasz
Adding Devrim...
On Wed, Nov 23, 2016 at 1:12 PM, Peter Juhasz <pjuhasz@uhusystems.com> wrote:
> Dear PgAdmin4 maintainers,
>
> I've installed the latest pgadmin4-v1 package from the PGDG repository.
> Unfortunately, it still does not work.
>
> Now (as oppossed to the previous version of the package) there is a
> pgadmin4 binary in the path, starting it results in the familiar "An
> error occurred initialising the application server: Failed to locate
> pgAdmin4.py, terminating server thread." message box and (usually) a
> segmentation fault.
>
> The reason for this is that the application does not know where to find
> the python server backend. On my machine, it tries the following
> locations:
>
> stat("/home/pjuhasz/.config/pgAdmin Development Team/pgAdmin 4.conf", 0x7ffcb842f9b0) = -1 ENOENT (No such file or
directory)
> stat("/home/pjuhasz/.config/pgAdmin Development Team/pgAdmin 4.conf", 0x7ffcb842f9b0) = -1 ENOENT (No such file or
directory)
> stat("/home/pjuhasz/.config/pgAdmin Development Team/pgAdmin 4.conf", 0x7ffcb842f990) = -1 ENOENT (No such file or
directory)
> stat("/home/pjuhasz/.config/pgAdmin Development Team.conf", 0x7ffcb842f9b0) = -1 ENOENT (No such file or directory)
> stat("/home/pjuhasz/.config/pgAdmin Development Team.conf", 0x7ffcb842f9b0) = -1 ENOENT (No such file or directory)
> stat("/home/pjuhasz/.config/pgAdmin Development Team.conf", 0x7ffcb842f990) = -1 ENOENT (No such file or directory)
> stat("/etc/xdg/pgAdmin Development Team/pgAdmin 4.conf", 0x7ffcb842f9b0) = -1 ENOENT (No such file or directory)
> stat("/etc/xdg/pgAdmin Development Team/pgAdmin 4.conf", 0x7ffcb842f9b0) = -1 ENOENT (No such file or directory)
> stat("/etc/xdg/pgAdmin Development Team/pgAdmin 4.conf", 0x7ffcb842f990) = -1 ENOENT (No such file or directory)
> stat("/etc/xdg/pgAdmin Development Team.conf", 0x7ffcb842f9b0) = -1 ENOENT (No such file or directory)
> stat("/etc/xdg/pgAdmin Development Team.conf", 0x7ffcb842f9b0) = -1 ENOENT (No such file or directory)
> stat("/etc/xdg/pgAdmin Development Team.conf", 0x7ffcb842f990) = -1 ENOENT (No such file or directory)
>
> Not knowing the correct path it tries /usr/pgadmin4-
> v1/runtime/pgAdmin4.py and even /pgAdmin4.py, then eventually gives up.
>
> The package installs a pgadmin4.ini next to the pgAdmin4 binary,
> containing the correct path, but this file is never accessed.
>
> The reason for this is that QSettings is used in the pgadmin4 program
> with default settings, which causes Qt to try the locations mentioned
> above. This behavior is documented at e.g. http://doc.qt.io/archives/qt
> -4.7/qsettings.html#platform-specific-notes .
>
> Something is still wrong, though, because the application does not
> start even after manually copying the provided pgadmin4.ini to one of
> the previously mentioned locations.
>
> I'd also like to mention that directory names with spaces and capital
> letters are discouraged (to put it lightly) in Linux.
>
>
> I can access the webapp from a browser after running "systemctl start
> pgadmin4-v1.service", but
> - this is not documented (AFAIK),
> - this is not something I want to do,
> - for users that don't have root permissions this might not be an
> option.
>
> Best regards,
> Peter Juhasz
>
>
>
> --
> Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgadmin-support
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Hi, On Wed, 2016-11-23 at 14:12 +0100, Peter Juhasz wrote: > I've installed the latest pgadmin4-v1 package from the PGDG repository. > Unfortunately, it still does not work. <snip> Is this a fresh installation, or did you upgrade from the previous RPMs? Regards, -- Devrim GÜNDÜZ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Twitter: @DevrimGunduz , @DevrimGunduzTR
On Tue, 2016-11-29 at 03:07 +0300, Devrim Gündüz wrote: > Hi, > > On Wed, 2016-11-23 at 14:12 +0100, Peter Juhasz wrote: > > > > I've installed the latest pgadmin4-v1 package from the PGDG > > repository. > > Unfortunately, it still does not work. > > <snip> > > Is this a fresh installation, or did you upgrade from the previous > RPMs? > > I've removed the previous pgadmin4-* packages then installed the new ones. Peter
On Tue, 2016-11-29 at 10:42 +0100, Peter Juhasz wrote: > I've removed the previous pgadmin4-* packages then installed the new > ones. That is not enough -- can you please also delete the directories that I mentioned here? https://www.postgresql.org/message-id/1479206529.4684.18.camel%40gunduz.org That error comes when these dirs are not removed. The previous packages were broken, and we need to get rid of all old stuff prior to installing new ones. Regards, -- Devrim GÜNDÜZ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Twitter: @DevrimGunduz , @DevrimGunduzTR
On Wed, 2016-11-30 at 21:56 +0300, Devrim Gündüz wrote: > On Tue, 2016-11-29 at 10:42 +0100, Peter Juhasz wrote: > > > > I've removed the previous pgadmin4-* packages then installed the > > new > > ones. > > That is not enough -- can you please also delete the directories that > I > mentioned here? > > https://www.postgresql.org/message-id/1479206529.4684.18.camel%40gund > uz.org > > That error comes when these dirs are not removed. The previous > packages were > broken, and we need to get rid of all old stuff prior to installing > new ones. > > Regards, I've removed the package, deleted those directories, then reinstalled the package. It didn't solve the problem - as I expected it wouldn't. As I've explained in my previous email, the problem is that the runtime application never learns the location of the python server (pgAdmin4.py) in the first place because it doesn't load the config file. On Linux, the QSettings class searches for the application's config file in the following locations: $HOME/.config/$ORGANIZATION_NAME/$APP_NAME.conf $HOME/.config/$ORGANIZATION_NAME.conf /etc/xdg/$ORGANIZATION_NAME/$APP_NAME.conf /etc/xdg/$ORGANIZATION_NAME.conf in this order. For pgAdmin4, on my system, these translate to /home/pjuhasz/.config/pgAdmin Development Team/pgAdmin 4.conf /home/pjuhasz/.config/pgAdmin Development Team.conf /etc/xdg/pgAdmin Development Team/pgAdmin 4.conf /etc/xdg/pgAdmin Development Team.conf None of these exist so the application displays the error popup and crashes. (More precisely, it displays the popup at pgAdmin4.cpp:87, so it doesn't even get the chance to display the other popup where the user could give the correct application/python path.) At this point I'll reiterate more bluntly that application/directory names with spaces in them are ugly, look out of place and potential sources of error. The rpm package installs two files that could be candidates for config files: /usr/pgadmin4-v1/runtime/pgadmin.ini /etc/pgAdmin\ Development\ Team/pgAdmin4.conf The first one is never accessed at all, its contents are misleading, so it's apparently there to confuse the user. The second one is almost good, except it should go in /etc/xdg, not in /etc. Apparently the ApplicationPath setting must be a relative path, absolute paths don't work (because of a bug at Server.cpp:221 where the code just blindly concatenates the config's Application path to the runtime's own directory - if Application path is an absolute path, it should be used as is). So after you copy the config file to its expected position under /etc/xdg, the contents must be modified as well: [General] ApplicationPath=../../../../../usr/lib/python3.5/site-packages/pgadmin4-web PythonPath="/usr/lib64/python3.5/site-packages;/usr/lib/python3.5/site-packages" Note the five ..'s. Having done this, the pgadmin4 command finally works! I hope this helps. Best regards, Peter Juhasz
On Thu, Dec 1, 2016 at 12:14 PM, Peter Juhasz <pjuhasz@uhusystems.com> wrote: > On Wed, 2016-11-30 at 21:56 +0300, Devrim Gündüz wrote: >> On Tue, 2016-11-29 at 10:42 +0100, Peter Juhasz wrote: >> > >> > I've removed the previous pgadmin4-* packages then installed the >> > new >> > ones. >> >> That is not enough -- can you please also delete the directories that >> I >> mentioned here? >> >> https://www.postgresql.org/message-id/1479206529.4684.18.camel%40gund >> uz.org >> >> That error comes when these dirs are not removed. The previous >> packages were >> broken, and we need to get rid of all old stuff prior to installing >> new ones. >> >> Regards, > > I've removed the package, deleted those directories, then reinstalled > the package. > > It didn't solve the problem - as I expected it wouldn't. > > As I've explained in my previous email, the problem is that the runtime > application never learns the location of the python server > (pgAdmin4.py) in the first place because it doesn't load the config > file. > > On Linux, the QSettings class searches for the application's config > file in the following locations: > > $HOME/.config/$ORGANIZATION_NAME/$APP_NAME.conf > $HOME/.config/$ORGANIZATION_NAME.conf > /etc/xdg/$ORGANIZATION_NAME/$APP_NAME.conf > /etc/xdg/$ORGANIZATION_NAME.conf > > in this order. For pgAdmin4, on my system, these translate to > > /home/pjuhasz/.config/pgAdmin Development Team/pgAdmin 4.conf > /home/pjuhasz/.config/pgAdmin Development Team.conf > /etc/xdg/pgAdmin Development Team/pgAdmin 4.conf > /etc/xdg/pgAdmin Development Team.conf We've found these locations seem to vary somewhat when testing with strace. FYI, I tested the new RPMs on CentOS 7 before they were published, and they work fine there - but I agree they're not working on Fedora having since tested them there too. > None of these exist so the application displays the error popup and > crashes. (More precisely, it displays the popup at pgAdmin4.cpp:87, so > it doesn't even get the chance to display the other popup where the > user could give the correct application/python path.) > > At this point I'll reiterate more bluntly that application/directory > names with spaces in them are ugly, look out of place and potential > sources of error. Agreed - blame Qt for that one. It builds the paths from the the company and product names. I'm going to change what they are. > The rpm package installs two files that could be candidates for config > files: > > /usr/pgadmin4-v1/runtime/pgadmin.ini That shouldn't be there. > /etc/pgAdmin\ Development\ Team/pgAdmin4.conf > > The first one is never accessed at all, its contents are misleading, so > it's apparently there to confuse the user. > > The second one is almost good, except it should go in /etc/xdg, not in > /etc. Yeah. > Apparently the ApplicationPath setting must be a relative path, > absolute paths don't work (because of a bug at Server.cpp:221 where the > code just blindly concatenates the config's Application path to the > runtime's own directory - if Application path is an absolute path, it > should be used as is). You're suggesting a fix such as this? snake:pgadmin4 dpage$ git diff diff --git a/runtime/Server.cpp b/runtime/Server.cpp index 3a4c660..e631872 100644 --- a/runtime/Server.cpp +++ b/runtime/Server.cpp @@ -218,7 +218,13 @@ bool Server::Init() for (int i = 0; i < paths.size(); ++i) { - QDir dir(QCoreApplication::applicationDirPath() + "/" + paths[i]); + QDir dir; + + if (paths[i].startsWith('/')) + dir = paths[i]; + else + dir = QCoreApplication::applicationDirPath() + "/" + paths[i]; + m_appfile = dir.canonicalPath() + "/pgAdmin4.py"; if (QFile::exists(m_appfile)) > So after you copy the config file to its expected position under > /etc/xdg, the contents must be modified as well: > > [General] > ApplicationPath=../../../../../usr/lib/python3.5/site-packages/pgadmin4-web > PythonPath="/usr/lib64/python3.5/site-packages;/usr/lib/python3.5/site-packages" > > Note the five ..'s. > > Having done this, the pgadmin4 command finally works! > > I hope this helps. > > Best regards, > Peter Juhasz > > > > -- > Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgadmin-support -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Fri, 2016-12-02 at 01:16 +0000, Dave Page wrote:
> On Thu, Dec 1, 2016 at 12:14 PM, Peter Juhasz <pjuhasz@uhusystems.com
> > wrote:
[...]
> > Apparently the ApplicationPath setting must be a relative path,
> > absolute paths don't work (because of a bug at Server.cpp:221 where
> > the
> > code just blindly concatenates the config's Application path to the
> > runtime's own directory - if Application path is an absolute path,
> > it
> > should be used as is).
>
> You're suggesting a fix such as this?
>
> snake:pgadmin4 dpage$ git diff
> diff --git a/runtime/Server.cpp b/runtime/Server.cpp
> index 3a4c660..e631872 100644
> --- a/runtime/Server.cpp
> +++ b/runtime/Server.cpp
> @@ -218,7 +218,13 @@ bool Server::Init()
>
> for (int i = 0; i < paths.size(); ++i)
> {
> - QDir dir(QCoreApplication::applicationDirPath() + "/" +
> paths[i]);
> + QDir dir;
> +
> + if (paths[i].startsWith('/'))
> + dir = paths[i];
> + else
> + dir = QCoreApplication::applicationDirPath() + "/" +
> paths[i];
> +
> m_appfile = dir.canonicalPath() + "/pgAdmin4.py";
>
> if (QFile::exists(m_appfile))
>
Yes - but does this work on Windows?
best regards,
Peter Juhasz
On Fri, Dec 2, 2016 at 10:39 AM, Peter Juhasz <pjuhasz@uhusystems.com> wrote:
> On Fri, 2016-12-02 at 01:16 +0000, Dave Page wrote:
>> On Thu, Dec 1, 2016 at 12:14 PM, Peter Juhasz <pjuhasz@uhusystems.com
>> > wrote:
> [...]
>
>> > Apparently the ApplicationPath setting must be a relative path,
>> > absolute paths don't work (because of a bug at Server.cpp:221 where
>> > the
>> > code just blindly concatenates the config's Application path to the
>> > runtime's own directory - if Application path is an absolute path,
>> > it
>> > should be used as is).
>>
>> You're suggesting a fix such as this?
>>
>> snake:pgadmin4 dpage$ git diff
>> diff --git a/runtime/Server.cpp b/runtime/Server.cpp
>> index 3a4c660..e631872 100644
>> --- a/runtime/Server.cpp
>> +++ b/runtime/Server.cpp
>> @@ -218,7 +218,13 @@ bool Server::Init()
>>
>> for (int i = 0; i < paths.size(); ++i)
>> {
>> - QDir dir(QCoreApplication::applicationDirPath() + "/" +
>> paths[i]);
>> + QDir dir;
>> +
>> + if (paths[i].startsWith('/'))
>> + dir = paths[i];
>> + else
>> + dir = QCoreApplication::applicationDirPath() + "/" +
>> paths[i];
>> +
>> m_appfile = dir.canonicalPath() + "/pgAdmin4.py";
>>
>> if (QFile::exists(m_appfile))
>>
>
> Yes - but does this work on Windows?
Yes, if you use forward slashes and the same drive as the runtime is
on - but I see no reason that would be a real problem; it's not like
end users are supposed to need to touch this stuff.
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company