Re: Newbie-ish HUP question (0.9.0) (solution - a bug?)
Yup. I spotted that also. I will try to clean them up over the next few days.
If you have some time can you give current CVS a whirl and see if it works for
you.
The function now looks like:
static int sql_destroy_socket(SQLSOCK *sqlsocket, SQL_CONFIG *config)
{
rlm_sql_postgres_sock *pg_sock = sqlsocket->conn;
free(pg_sock);
return 0;
}
There is some NASTY code in some of the DB drivers.. Other people are welcome
to help me clean them up :-)
Peter
On Thu July 31 2003 21:15, Alex Chen wrote:
> This not_implemented function is also present in other SQL driver modules,
> e.g. DB2.
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] Behalf Of
> > Alan DeKok
> > Sent: Thursday, July 31, 2003 7:08 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Newbie-ish HUP question (0.9.0) (solution - a bug?)
> >
> > Peter Nixon <[EMAIL PROTECTED]> wrote:
> > > If I have time (and no one else beats me to it) I will
> >
> > implement this
> >
> > > tonight..
> >
> > Please also get rid of the "not_implemented" function in
> > sql_postgresql.c. It's evil.
> >
> > Alan DeKok.
> >
> > -
> > List info/subscribe/unsubscribe? See
> > http://www.freeradius.org/list/users.html
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
--
Peter Nixon
http://www.peternixon.net/
PGP Key: http://www.peternixon.net/public.asc
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Newbie-ish HUP question (0.9.0) (solution - a bug?)
This not_implemented function is also present in other SQL driver modules, e.g. DB2. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > Alan DeKok > Sent: Thursday, July 31, 2003 7:08 AM > To: [EMAIL PROTECTED] > Subject: Re: Newbie-ish HUP question (0.9.0) (solution - a bug?) > > > Peter Nixon <[EMAIL PROTECTED]> wrote: > > If I have time (and no one else beats me to it) I will > implement this > > tonight.. > > Please also get rid of the "not_implemented" function in > sql_postgresql.c. It's evil. > > Alan DeKok. > > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Newbie-ish HUP question (0.9.0) (solution - a bug?)
Peter Nixon <[EMAIL PROTECTED]> wrote: > If I have time (and no one else beats me to it) I will implement this > tonight.. Please also get rid of the "not_implemented" function in sql_postgresql.c. It's evil. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Newbie-ish HUP question (0.9.0) (solution - a bug?)
On Thu, 31 Jul 2003 02:45 pm, Fenn Bailey wrote: > > > try to comment any change you did on it, just in order to > > > follow the normal > > > course of the application. > > > > Thanks for the tip, the main problem is it does it even if I > > don't touch any > > files at all, eg: just start it and issue a HUP. I have also > > found, it does > > the same thing with any signal sent to the process; it outputs > > that "Error: > > sql_postgresql: calling unimplemented" message and dies. Probably > > not a good > > thing :) > > OK, did some further testing and have come to the conclusion it is a bug > (developers, opinions ;) > > Basically, without looking at it in too much detailed, I worked out that > the daemon was calling sql_destroy_socket on the rlm_sql_postgres module, > which doesn't implement the method. Since calls to non implemented > functions causes an exit(), the whole daemon (almost) silently dies > whenever a HUP (or other signal that would cause a call to > sql_destroy_socket). > > I implemented the destroy_socket function (it just does nothing) and > rebuild and voila - all good now :) I would like to propose (I'm willing to > do this myself if desired by the team via a patch or whatever) to both fix > this bug, and have the not_implemented function at least die with some > useful information. > > The output now (on my version) looks like this upon being given a HUP: > --- > Thu Jul 31 21:31:29 2003 : Info: Reloading configuration files. > Thu Jul 31 21:31:30 2003 : Error: sql_postgresql: sql_destroy_socket called > erroneously > Thu Jul 31 21:31:30 2003 : Error: sql_postgresql: sql_destroy_socket called > erroneously > Thu Jul 31 21:31:30 2003 : Error: sql_postgresql: sql_destroy_socket called > erroneously > Thu Jul 31 21:31:30 2003 : Error: sql_postgresql: sql_destroy_socket called > erroneously > Thu Jul 31 21:31:30 2003 : Error: sql_postgresql: sql_destroy_socket called > erroneously > Thu Jul 31 21:31:30 2003 : Info: rlm_sql (sql): Driver rlm_sql_postgresql > (module rlm_sql_postgresql) loaded and linked > Thu Jul 31 21:31:30 2003 : Info: rlm_sql (sql): Attempting to connect to > [EMAIL PROTECTED]:/freerad > Thu Jul 31 21:31:30 2003 : Info: Ready to process requests. > --- > > Either way, I hope I helped out someone else who may be suffering the same > issue. If I have time (and no one else beats me to it) I will implement this tonight.. -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Newbie-ish HUP question (0.9.0) (solution - a bug?)
> > try to comment any change you did on it, just in order to > > follow the normal > > course of the application. > > > > Thanks for the tip, the main problem is it does it even if I > don't touch any > files at all, eg: just start it and issue a HUP. I have also > found, it does > the same thing with any signal sent to the process; it outputs > that "Error: > sql_postgresql: calling unimplemented" message and dies. Probably > not a good > thing :) > OK, did some further testing and have come to the conclusion it is a bug (developers, opinions ;) Basically, without looking at it in too much detailed, I worked out that the daemon was calling sql_destroy_socket on the rlm_sql_postgres module, which doesn't implement the method. Since calls to non implemented functions causes an exit(), the whole daemon (almost) silently dies whenever a HUP (or other signal that would cause a call to sql_destroy_socket). I implemented the destroy_socket function (it just does nothing) and rebuild and voila - all good now :) I would like to propose (I'm willing to do this myself if desired by the team via a patch or whatever) to both fix this bug, and have the not_implemented function at least die with some useful information. The output now (on my version) looks like this upon being given a HUP: --- Thu Jul 31 21:31:29 2003 : Info: Reloading configuration files. Thu Jul 31 21:31:30 2003 : Error: sql_postgresql: sql_destroy_socket called erroneously Thu Jul 31 21:31:30 2003 : Error: sql_postgresql: sql_destroy_socket called erroneously Thu Jul 31 21:31:30 2003 : Error: sql_postgresql: sql_destroy_socket called erroneously Thu Jul 31 21:31:30 2003 : Error: sql_postgresql: sql_destroy_socket called erroneously Thu Jul 31 21:31:30 2003 : Error: sql_postgresql: sql_destroy_socket called erroneously Thu Jul 31 21:31:30 2003 : Info: rlm_sql (sql): Driver rlm_sql_postgresql (module rlm_sql_postgresql) loaded and linked Thu Jul 31 21:31:30 2003 : Info: rlm_sql (sql): Attempting to connect to [EMAIL PROTECTED]:/freerad Thu Jul 31 21:31:30 2003 : Info: Ready to process requests. --- Either way, I hope I helped out someone else who may be suffering the same issue. Thanks all, Fenn. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Newbie-ish HUP question (0.9.0)
> It looks like you modified a file it was used originally to configure
> freeradius and you shouldn't use it anymore. Try to check
> with the HowTo to
> see if you are changing the files you should and if you
> changed other one
> try to comment any change you did on it, just in order to
> follow the normal
> course of the application.
>
> It used to happen that if you change one old file like the
> "clients" instead
> of "clients.conf" it refuses to work. :)
Thanks for the tip, the main problem is it does it even if I don't touch any
files at all, eg: just start it and issue a HUP. I have also found, it does
the same thing with any signal sent to the process; it outputs that "Error:
sql_postgresql: calling unimplemented" message and dies. Probably not a good
thing :)
I deleted the deprecated clients, realms and naslist files (you can see the
open failure below) and included the strace output. It looks much the same
unfortunately :\
---
read(15, "#\n# dictionary.wispr\n#\n#\tVSAs or"..., 4096) = 996
read(15, "", 4096) = 0
close(15) = 0
munmap(0x4024d000, 4096)= 0
open("/usr/share/freeradius/dictionary.xedia", O_RDONLY) = 15
fstat64(15, {st_mode=S_IFREG|0644, st_size=766, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x4024d000
read(15, ""..., 4096) = 766
read(15, "", 4096) = 0
close(15) = 0
munmap(0x4024d000, 4096)= 0
read(14, "3\tinteger\nATTRIBUTE\tAcct-Session"..., 4096) = 4096
read(14, "\t1010\tdate\nATTRIBUTE\tAutz-Type\t\t"..., 4096) = 4096
read(14, " Acct-Terminate-CauseId"..., 4096) = 4096
read(14, "e\tAccounting-Request\t\t4\nVALUE\t\tR"..., 4096) = 462
read(14, "", 4096) = 0
close(14) = 0
munmap(0x40216000, 4096)= 0
read(13, "", 4096) = 0
close(13) = 0
munmap(0x40017000, 4096)= 0
open("/etc/freeradius/naslist", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/etc/freeradius/clients", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/etc/freeradius/realms", O_RDONLY) = -1 ENOENT (No such file or
directory)
getrlimit(0x4, 0xbfffe520) = 0
setrlimit(RLIMIT_CORE, {rlim_cur=0, rlim_max=RLIM_INFINITY}) = 0
open("/etc/group", O_RDONLY)= 13
fcntl64(13, F_GETFD)= 0
fcntl64(13, F_SETFD, FD_CLOEXEC)= 0
fstat64(13, {st_mode=S_IFREG|0644, st_size=519, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x40017000
_llseek(13, 0, [0], SEEK_CUR) = 0
read(13, "root:x:0:\ndaemon:x:1:\nbin:x:2:\ns"..., 4096) = 519
close(13) = 0
munmap(0x40017000, 4096)= 0
setgid32(0x67) = 0
open("/etc/passwd", O_RDONLY) = 13
fcntl64(13, F_GETFD)= 0
fcntl64(13, F_SETFD, FD_CLOEXEC)= 0
fstat64(13, {st_mode=S_IFREG|0644, st_size=1354, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x40017000
_llseek(13, 0, [0], SEEK_CUR) = 0
read(13, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 1354
close(13) = 0
munmap(0x40017000, 4096)= 0
setuid32(0x69) = 0
munmap(0x40234000, 10040) = 0
munmap(0x40237000, 11824) = 0
rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_IGN}, 8) = 0
send(7, "X", 1, 0) = 1
rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_IGN}, 8) = 0
close(7)= 0
open("/var/log/freeradius/radius.log", O_WRONLY|O_APPEND|O_CREAT, 0666) = 7
fstat64(7, {st_mode=S_IFREG|0644, st_size=30259, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x40017000
fstat64(7, {st_mode=S_IFREG|0644, st_size=30259, ...}) = 0
_llseek(7, 30259, [30259], SEEK_SET)= 0
time(NULL) = 1059609253
write(7, "Thu Jul 31 09:54:13 2003 : Error"..., 81) = 81
close(7)= 0
munmap(0x40017000, 4096)= 0
write(12, "[EMAIL PROTECTED]"..., 148)
= 148
rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 8) = 0
rt_sigsuspend([]
--- SIGRTMIN (Real-time signal 0) ---
<... rt_sigsuspend resumed> ) = -1 EINTR (Interrupted system call)
sigreturn() = ? (mask now [RTMIN])
wait4(9795, NULL, __WCLONE, NULL) = 9795
munmap(0x40014000, 4096)= 0
_exit(1)
---
Fenn.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Newbie-ish HUP question (0.9.0)
- Original Message - From: "Fenn Bailey" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, July 30, 2003 2:06 AM Subject: Newbie-ish HUP question (0.9.0) > read_config_files: reading dictionary > read_config_files: reading naslist > Using deprecated naslist file. Support for this will go away soon. > read_config_files: reading clients > Using deprecated clients file. Support for this will go away soon. > read_config_files: reading realms > Using deprecated realms file. Support for this will go away soon. > > - It looks like you modified a file it was used originally to configure freeradius and you shouldn't use it anymore. Try to check with the HowTo to see if you are changing the files you should and if you changed other one try to comment any change you did on it, just in order to follow the normal course of the application. It used to happen that if you change one old file like the "clients" instead of "clients.conf" it refuses to work. :) Bye Ivan D. Barrera EECIS Staff University of Delaware. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Newbie-ish HUP question (0.9.0)
> I'm wondering if anyone can help me trackdown what exactly might be
> happening (or, if I'm doing something REALLY dumb, then to
> beat me severely
> with a clue-stick).
>
Ok, I realise I jumped the gun slightly in my eagerness for help (though
still not fixed) - here's a bit more info:
Log output AFTER the HUP is:
---
Wed Jul 30 16:08:19 2003 : Info: Reloading configuration files.
Wed Jul 30 16:08:19 2003 : Info: Using deprecated naslist file. Support for
this will go away soon.
Wed Jul 30 16:08:19 2003 : Info: Using deprecated clients file. Support for
this will go away soon.
Wed Jul 30 16:08:19 2003 : Info: Using deprecated realms file. Support for
this will go away soon.
Wed Jul 30 16:08:19 2003 : Error: sql_postgresql: calling unimplemented
function
---
So it's obviously a postgres module related issue (odd that it starts and
works, but fails on HUP).
Here's the tail of a strace output off the master process/thread:
---
read(13, "#\n#\tTHIS FILE IS DEPRECATED.\n#\n#"..., 4096) = 1387
read(13, "", 4096) = 0
close(13) = 0
munmap(0x40017000, 4096)= 0
getrlimit(0x4, 0xbfffe500) = 0
setrlimit(RLIMIT_CORE, {rlim_cur=0, rlim_max=RLIM_INFINITY}) = 0
open("/etc/group", O_RDONLY)= 13
fcntl64(13, F_GETFD)= 0
fcntl64(13, F_SETFD, FD_CLOEXEC)= 0
fstat64(13, {st_mode=S_IFREG|0644, st_size=519, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x40017000
_llseek(13, 0, [0], SEEK_CUR) = 0
read(13, "root:x:0:\ndaemon:x:1:\nbin:x:2:\ns"..., 4096) = 519
close(13) = 0
munmap(0x40017000, 4096)= 0
setgid32(0x67) = 0
open("/etc/passwd", O_RDONLY) = 13
fcntl64(13, F_GETFD)= 0
fcntl64(13, F_SETFD, FD_CLOEXEC)= 0
fstat64(13, {st_mode=S_IFREG|0644, st_size=1354, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x40017000
_llseek(13, 0, [0], SEEK_CUR) = 0
read(13, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 1354
close(13) = 0
munmap(0x40017000, 4096)= 0
setuid32(0x69) = 0
munmap(0x4023d000, 10040) = 0
munmap(0x4024, 11824) = 0
rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_IGN}, 8) = 0
send(7, "X", 1, 0) = 1
rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_IGN}, 8) = 0
close(7)= 0
open("/var/log/freeradius/radius.log", O_WRONLY|O_APPEND|O_CREAT, 0666) = 7
fstat64(7, {st_mode=S_IFREG|0644, st_size=24247, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x40017000
fstat64(7, {st_mode=S_IFREG|0644, st_size=24247, ...}) = 0
_llseek(7, 24247, [24247], SEEK_SET)= 0
time(NULL) = 1059545186
write(7, "Wed Jul 30 16:06:26 2003 : Error"..., 81) = 81
close(7)= 0
munmap(0x40017000, 4096)= 0
write(12, "[EMAIL PROTECTED](\371\22\10\310\377\22\10`="..., 148)
= 148
rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 8) = 0
rt_sigsuspend([]
--- SIGRTMIN (Real-time signal 0) ---
<... rt_sigsuspend resumed> ) = -1 EINTR (Interrupted system call)
sigreturn() = ? (mask now [RTMIN])
wait4(4570, NULL, __WCLONE, NULL) = 4570
munmap(0x40014000, 4096)= 0
_exit(1)= ?
---
By the way, this is built/installed using the debian packaging stuff under
/debian in the tarball.
Thanks heaps again,
Fenn.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
