perl function getgrent not worked with libnss #16208
Comments
From asper@tagan.ruCreated by asper@tagan.ruperl function getgrent not worked in perl higer 5.20.x I prepared a simple test script to check this my nsswitch config file group: pgsql files #passwd: compat # passwd: db files nis hosts: files dns services: db files automount: files system utils Perl Info |
From @jkeenanOn Mon, 23 Oct 2017 10:55:44 GMT, asper@tagan.ru wrote:
Do you get any output at all if it is enable to take groups and users from the database?
-- |
|
The RT System itself - Status changed from 'new' to 'open' |
From asper@tagan.ru23.10.2017 23:26, James E Keenan via RT пи�е�:
We use the x2go server, when upgrading the pearl above 5.20 clients can not connect to the server.
-- Megalink Company, Engineer |
From @jkeenanOn Thu, 26 Oct 2017 03:52:19 GMT, asper@tagan.ru wrote:
This is going to be difficult for us to debug because there are several factors --- the x2go server, the libnss-pgsql library, the use of a database for NSS -- which are outside the scope of the Perl 5 core distribution and which will be difficult for our readers to emulate. So I am grasping at straws here. Do you experience the same problem if you use the User::grent module included in the core distribution? (see attachment) Thank you very much. -- |
From @jkeenan |
From asper@tagan.ruusing the User::grent module, the grant also causes a hang. I ran the test script that you sent - it hangs. To verify, you really need a library of libnss and a postgres database x2go server is not needed I also checked this script in ubuntu with the included libnsss library there, too, hangs 27.10.2017 16:41, James E Keenan via RT пи�е�:
-- Megalink Company, Engineer |
From @jkeenanOn Sat, 28 Oct 2017 22:25:19 GMT, asper@tagan.ru wrote:
Could you clarify what you mean exactly by that? Which script is "this script"? When you refer to "the included libnss library", are you referring, say, to libnss3? Or to something else? I ask this because if we can demonstrate a problem with libnss (of some sort) not connected to PostgreSQL, then we may have a better handle on the problem. Thank you very much. -- |
From asper@tagan.ruUnder the script, I meant perl -e 'while ($a =getgrent) {print $a . "\n";}' AND # perl while (my $y = getgrent()) { I do not know how to get hung without a postgres database for testing, I tried to use another library nss-userfiles with it the function getgrent does not hang I am attaching two trace files. One trace of the execution of the perl script. The second system utility. 29.10.2017 03:40, James E Keenan via RT пи�е�:
-- Megalink Company, Engineer |
From asper@tagan.rugbase ~ # strace getent group |
From asper@tagan.rugbase ~ # strace perl -e 'while ($a =getgrent) {print $a . "\n";}' |
From asper@tagan.ruI want to inform you that I found a solution to the problem. I rebuilt in the debugging mode, glibc, linss-pgsgl, perl 5.24 and through the tracer found a function in which hangs. This is a function in the libnss_pgsqll library. after changing the lock type in a libnss_pgsql with MUTEX to RECURSIVE_MUTEX, the getgrent function stops hanging. however I still do not understand what changed in the perl after version 5.20 and caused the getgrent to hang 30.10.2017 15:09, �и�аил �ане�ко пи�е�:
-- Megalink Company, Engineer |
From @jkeenanOn 11/01/2017 09:49 AM, �и�аил �ане�ко wrote:
Would you be able to post that trace and your work-around? Even if we
Nor do I. I couldn't see any modifications to the source code for
|
From @tonycozOn Wed, Nov 01, 2017 at 04:49:05PM +0300, �и�аил �ане�ко wrote:
Is there any chance you switched from an unthreaded build of perl to a You might want to try building with -Ud_getgrent_r Looking at the ChangeLog for libnss-pgsql2, I see: * Fixed bug where if you used getpwent, then getspnam, then getpwent I wonder if there's a similar problem with groups. Tony |
From asper@tagan.ru02.11.2017 08:55, Tony Cook via RT пи�е�:
I downloaded the perl from the git repository. asper@a ~/INSTALL/perl $ git remote -v
I rebuild perl with
I saw the commit described in Cgangelog libnss_pgsql2, these fixes relate to lib_nss of the function getent_close and partial sequence is called when getgrent ...
A more detailed study showed that a pearl above 5.20 hides using two functions, getgrent and getpwent. Here is the patch I applied to the libnss_pgsql2 library, this patch fixes both functions , getgrent and getpwent. Inline Patchdiff --git a/src/interface.c b/src/interface.c
index 7c6475c..ced21c6 100644
--- a/src/interface.c
+++ b/src/interface.c
@@ -10,12 +10,13 @@
*
*/
+#define _GNU_SOURCE
#include "nss-pgsql.h"
#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>
-static pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
+static pthread_mutex_t lock = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
/*
* passwd functions
@@ -250,7 +251,7 @@ _nss_pgsql_getspent_r(struct spwd *result, char *buffer,
{
enum nss_status retval = NSS_STATUS_UNAVAIL;
int lerrno = 0;
-
+
pthread_mutex_lock(&lock);
// Make sure the database is opened in case no one has called setspent()
-- Regards, Megalink Company, Engineer |
From @tonycozOn Thu, Nov 02, 2017 at 01:50:57PM +0300, �и�аил �ане�ко wrote:
Ok, thanks.
Yes, but I can only see that lock being held if there's a bug in libnss_pgsql. I had a look, getgrent() (from 1.4.0) is: enum nss_status __libc_lock_lock(lock); // Make sure the database is opened in case no one has called setpwent() if(backend_isopen(CONNECTION_USERGROUP)) { return retval; Note the call to _nss_pgsql_setgrent() with the lock held. enum nss_status __libc_lock_lock(lock); return NSS_STATUS_SUCCESS; attempts to lock too, and in the call from _nss_pgsql_getgrent_r() it So this appears to be a libnss_pgsql bug, which your change to Tony |
|
Reviewing this older ticket, it appears that @tonycoz diagnosed the problem as being in an outside library. Since we haven't heard anything more in 4 years, I will take this ticket for the purpose of closing it within 7 days unless someone has a serious objection. Thank you very much. |
No objections heard; closing ticket as per previous post. |
Migrated from rt.perl.org#132351 (status was 'open')
Searchable as RT132351$
The text was updated successfully, but these errors were encountered: