Error: FATAL Failed to initialize semaphore: Function not implemented
Hi, Haven't built a new copy of the server for a while, as I was mostly debugging config stuff. When I have built a new copy of the server from CVS i've always ran it in full foreground debugging mode which disables threads... Which is why I don't know exactly when the commit that causes this was done ... In Full debugging mode radiusd -X is fine However running in daemon mode with debugging on I get: Thu Aug 2 12:15:22 2007 : Debug: } Thu Aug 2 12:15:22 2007 : Debug: Initializing the thread pool... Thu Aug 2 12:15:22 2007 : Debug: thread pool { Thu Aug 2 12:15:22 2007 : Debug: start_servers = 5 Thu Aug 2 12:15:22 2007 : Debug: max_servers = 32 Thu Aug 2 12:15:22 2007 : Debug: min_spare_servers = 3 Thu Aug 2 12:15:22 2007 : Debug: max_spare_servers = 10 Thu Aug 2 12:15:22 2007 : Debug: max_requests_per_server = 20 Thu Aug 2 12:15:22 2007 : Debug: cleanup_delay = 5 Thu Aug 2 12:15:22 2007 : Debug: max_queue_size = 65536 Thu Aug 2 12:15:22 2007 : Debug: } Thu Aug 2 12:15:22 2007 : Error: FATAL: Failed to initialize semaphore: Function not implemented At which point GDB reports that the program exited normally, and so won't give me the backtrace of the stack. *sigh* According to my colleague (who has now gone off on holiday) : "there's an issue to do with the way semaphores are implemented on OS X (basically, you can't use "unnamed" ones -- there's a very old thread about this in the freeradius-users list from 2004, with workarounds). I'm guessing that there's something wrong in the "configure" for OS X, meaning that it isn't using the right flavour of semaphore initialisation, OR that 2.0 has a regression to the previous problem that was fixed in 1.x" Any chance someone could take a look at this ? Be happy to provide any extra information required. Thanks, Arran
Arran Cudbard-Bell wrote:
"there's an issue to do with the way semaphores are implemented on OS X (basically, you can't use "unnamed" ones -- there's a very old thread about this in the freeradius-users list from 2004, with workarounds). I'm guessing that there's something wrong in the "configure" for OS X, meaning that it isn't using the right flavour of semaphore initialisation, OR that 2.0 has a regression to the previous problem that was fixed in 1.x"
Pretty much, but the relevant code wasn't changed in 2.0, either in configure or in src/main/threads.c.
Any chance someone could take a look at this ?
Be happy to provide any extra information required.
Apple just released their version of the code. I'll take a look to see if there's anything special there. It may also be useful for me to have SSH access to a Mac box. Alan DeKok.
There aren't any Apple changes to threading. I just tried running radiusd in daemon mode with the Apple version and got the same error. When we run radiusd, it's through launchd, which serves the same purpose as xinetd on other platforms to keep the process running. We run the process with args "-sf" to stop daemonization and run as a child of launchd. To run radiusd this way, create a file named "/System/Library/ LaunchDaemons/org.freeradius.radiusd.plist" with the contents: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http:// www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Disabled</key> <false/> <key>Label</key> <string>org.freeradius.radiusd</string> <key>OnDemand</key> <false/> <key>Program</key> <string>/usr/sbin/radiusd</string> <key>ProgramArguments</key> <array> <string>/usr/sbin/radiusd</string> <string>-sf</string> </array> <key>ServiceIPC</key> <false/> </dict> </plist> Run "launchctl load /System/Library/LaunchDaemons/ org.freeradius.radiusd.plist" to start radiusd. - Steve On Aug 3, 2007, at 5:43 AM, Alan DeKok wrote:
Arran Cudbard-Bell wrote:
"there's an issue to do with the way semaphores are implemented on OS X (basically, you can't use "unnamed" ones -- there's a very old thread about this in the freeradius-users list from 2004, with workarounds). I'm guessing that there's something wrong in the "configure" for OS X, meaning that it isn't using the right flavour of semaphore initialisation, OR that 2.0 has a regression to the previous problem that was fixed in 1.x"
Pretty much, but the relevant code wasn't changed in 2.0, either in configure or in src/main/threads.c.
Any chance someone could take a look at this ?
Be happy to provide any extra information required.
Apple just released their version of the code. I'll take a look to see if there's anything special there. It may also be useful for me to have SSH access to a Mac box.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/ devel.html
Steven Simon wrote:
There aren't any Apple changes to threading. I just tried running radiusd in daemon mode with the Apple version and got the same error.
When we run radiusd, it's through launchd, which serves the same purpose as xinetd on other platforms to keep the process running.
We run the process with args "-sf" to stop daemonization and run as a child of launchd.
To run radiusd this way, create a file named "/System/Library/ LaunchDaemons/org.freeradius.radiusd.plist" with the contents:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http:// www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Disabled</key> <false/> <key>Label</key> <string>org.freeradius.radiusd</string> <key>OnDemand</key> <false/> <key>Program</key> <string>/usr/sbin/radiusd</string> <key>ProgramArguments</key> <array> <string>/usr/sbin/radiusd</string> <string>-sf</string> </array> <key>ServiceIPC</key> <false/> </dict> </plist>
Run "launchctl load /System/Library/LaunchDaemons/ org.freeradius.radiusd.plist" to start radiusd.
- Steve
On Aug 3, 2007, at 5:43 AM, Alan DeKok wrote:
Thanks Steve, Yes we already tried this :) Unfortunately because we are using multi cored servers, theres going to be a big performance hit running it in single thread mode. We will have to do this if the issue isn't resolved though *sigh* This has only happened in the last month or so, I remember everything running fine before then. --- Arran
Arran Cudbard-Bell wrote:
This has only happened in the last month or so, I remember everything running fine before then.
What does "config.guess" say? The "configure" script sets -DDARWIN if config.guess says *darwin. If the "Make.inc" file has CFLAGS = .... -DDARWIN, then it *should* work. Or, maybe it's a run-time linking issue. Alan DeKok.
Alan DeKok wrote:
Arran Cudbard-Bell wrote:
This has only happened in the last month or so, I remember everything running fine before then.
What does "config.guess" say?
powerpc-apple-darwin8.9.0
The "configure" script sets -DDARWIN if config.guess says *darwin. If the "Make.inc" file has CFLAGS = .... -DDARWIN, then it *should* work.
CFLAGS = $(INCLUDE) -g -O2 Make output confirms --DDARWIN not passed to gcc at compile time.
Or, maybe it's a run-time linking issue.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Arran Cudbard-Bell wrote:
What does "config.guess" say?
powerpc-apple-darwin8.9.0
Well, that should work. If it stopped working, nothing in FreeRADIUS changed.
Make output confirms --DDARWIN not passed to gcc at compile time.
Try doing "cvs update src/include" from the CVS head. It should define DARWIN in src/include/missing.h. I also added (untested) Apple's patch for OpenDirectory support to rlm_mschap. It might break the build... Alan DeKok.
Alan DeKok wrote:
Arran Cudbard-Bell wrote:
What does "config.guess" say?
powerpc-apple-darwin8.9.0
Well, that should work. If it stopped working, nothing in FreeRADIUS changed.
Make output confirms --DDARWIN not passed to gcc at compile time.
Try doing "cvs update src/include" from the CVS head. It should define DARWIN in src/include/missing.h.
I also added (untested) Apple's patch for OpenDirectory support to rlm_mschap. It might break the build...
gcc -g -O2 -I/usr/local/src/freeradius-cvscurrent/src -I/usr/local/src/freeradius-cvscurrent/libltdl -c rlm_mschap.c: In function 'od_mschap_auth': rlm_mschap.c:75: error: storage class specified for parameter 'pdb_decode_acct_ctrl' rlm_mschap.c:75: error: parse error before '{' token rlm_mschap.c:77: error: parameter 'finished' is initialized rlm_mschap.c:84: error: parse error before 'if' rlm_mschap.c:84: error: old-style parameter declarations in prototyped function definition rlm_mschap.c:87: error: 'p' undeclared (first use in this function) rlm_mschap.c:87: error: (Each undeclared identifier is reported only once rlm_mschap.c:87: error: for each function it appears in.) rlm_mschap.c:89: error: 'acct_ctrl' undeclared (first use in this function) rlm_mschap.c:140: error: 'finished' undeclared (first use in this function) rlm_mschap.c: At top level: rlm_mschap.c:145: error: parse error before 'return' rlm_mschap.c: In function 'ntpwdhash': rlm_mschap.c:170: warning: pointer targets in passing argument 2 of 'md4_calc' differ in signedness rlm_mschap.c: In function 'challenge_hash': rlm_mschap.c:189: warning: pointer targets in passing argument 2 of 'librad_SHA1Update' differ in signed rlm_mschap.c: In function 'auth_response': rlm_mschap.c:230: warning: pointer targets in passing argument 1 of 'challenge_hash' differ in signednes rlm_mschap.c:230: warning: pointer targets in passing argument 2 of 'challenge_hash' differ in signednes rlm_mschap.c:230: warning: pointer targets in passing argument 4 of 'challenge_hash' differ in signednes rlm_mschap.c:233: warning: pointer targets in passing argument 2 of 'librad_SHA1Update' differ in signed rlm_mschap.c: In function 'mschap_xlat': rlm_mschap.c:559: warning: pointer targets in passing argument 1 of 'smbdes_lmpwdhash' differ in signedn rlm_mschap.c: In function 'mschap_instantiate': rlm_mschap.c:671: warning: assignment discards qualifiers from pointer target type rlm_mschap.c:672: warning: assignment discards qualifiers from pointer target type rlm_mschap.c: In function 'do_mschap': rlm_mschap.c:778: warning: pointer targets in passing argument 1 of 'smbdes_mschap' differ in signedness rlm_mschap.c:789: warning: pointer targets in passing argument 2 of 'md4_calc' differ in signedness rlm_mschap.c: In function 'mschap_authenticate': rlm_mschap.c:1082: warning: pointer targets in passing argument 2 of 'lrad_hex2bin' differ in signedness rlm_mschap.c:1100: warning: pointer targets in passing argument 1 of 'smbdes_lmpwdhash' differ in signed rlm_mschap.c:1100: warning: pointer targets in passing argument 2 of 'smbdes_lmpwdhash' differ in signed rlm_mschap.c:1114: warning: pointer targets in passing argument 2 of 'lrad_hex2bin' differ in signedness rlm_mschap.c:1132: warning: pointer targets in passing argument 1 of 'ntpwdhash' differ in signedness rlm_mschap.c:1285: warning: pointer targets in passing argument 4 of 'auth_response' differ in signednes rlm_mschap.c:1285: warning: pointer targets in passing argument 5 of 'auth_response' differ in signednes rlm_mschap.c:1285: warning: pointer targets in passing argument 6 of 'auth_response' differ in signednes rlm_mschap.c:1287: warning: pointer targets in passing argument 4 of 'add_reply' differ in signedness rlm_mschap.c:1354: warning: pointer targets in passing argument 3 of 'mppe_add_reply' differ in signedne rlm_mschap.c:1363: warning: pointer targets in passing argument 3 of 'mppe_add_reply' differ in signedne rlm_mschap.c:1366: warning: pointer targets in passing argument 3 of 'mppe_add_reply' differ in signedne make[6]: *** [rlm_mschap.lo] Error 1 make[5]: *** [common] Error 2 make[4]: *** [all] Error 2 make[3]: *** [common] Error 2 make[2]: *** [all] Error 2 make[1]: *** [common] Error 2 make: *** [all] Error 2 *sigh*
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Arran Cudbard-Bell wrote:
gcc -g -O2 -I/usr/local/src/freeradius-cvscurrent/src -I/usr/local/src/freeradius-cvscurrent/libltdl -c rlm_mschap.c: In function 'od_mschap_auth':
Missed a semi-colon. Couldn't test it because I don't have a Mac I can build on.
*sigh*
SSH key in separate mail. Alan DeKok.
Alan DeKok wrote:
Arran Cudbard-Bell wrote:
gcc -g -O2 -I/usr/local/src/freeradius-cvscurrent/src -I/usr/local/src/freeradius-cvscurrent/libltdl -c rlm_mschap.c: In function 'od_mschap_auth':
Missed a semi-colon. Couldn't test it because I don't have a Mac I can build on.
*sigh*
SSH key in separate mail.
Will get that sorted on monday :) --- gcc -g -O2 -I/usr/local/src/freeradius-cvscurrent/src -I/usr/local/src/freeradius-cvscurrent/libltdl -c opendir.c -fno-common -DPIC -o .l opendir.c: In function 'od_mschap_auth': opendir.c:213: error: 'struct value_pair' has no member named 'strvalue' opendir.c:269: error: 'struct value_pair' has no member named 'strvalue' opendir.c:279: error: 'struct value_pair' has no member named 'strvalue' opendir.c:285: error: 'struct value_pair' has no member named 'strvalue' opendir.c:295: error: 'struct value_pair' has no member named 'strvalue' opendir.c:301: error: 'struct value_pair' has no member named 'strvalue' opendir.c:311: error: 'struct value_pair' has no member named 'strvalue' opendir.c:339: error: 'struct value_pair' has no member named 'strvalue' --- Arran
Arran Cudbard-Bell wrote:
Alan DeKok wrote:
Arran Cudbard-Bell wrote:
gcc -g -O2 -I/usr/local/src/freeradius-cvscurrent/src -I/usr/local/src/freeradius-cvscurrent/libltdl -c rlm_mschap.c: In function 'od_mschap_auth':
Missed a semi-colon. Couldn't test it because I don't have a Mac I can build on.
*sigh*
SSH key in separate mail.
Will get that sorted on monday :)
---
Ok now compiles fine, and the semaphore issue seems sorted , thanks :) So you can authenticate against open directory now ? Thats pretty neat.. Unfortunately , although were an apple shop, we just use Open LDAP for authentication directly so I can't test it.
--- Arran
Arran Cudbard-Bell wrote:
So you can authenticate against open directory now ? Thats pretty neat.. Unfortunately , although were an apple shop, we just use Open LDAP for authentication directly so I can't test it.
Yes. There's also an rlm_opendirectory module that should go in at some point, too. Alan DeKok.
Hi, SQL based nas query, expects 5 fields , Row ID , Name (Used to identify the client) , Shortname , Type and Secret. I was wondering if it was possible / easy , to make RowID available as the request attribute Client-Uniqueid. That can be then used in subsequent queries to retrieve information about the connecting client. We were originally using Called-Station-Id , and then matching it to the hw_address of the record in our DB, but we then realised some NAS were sending Called-Station-Id's which bore little resemblance to their base mac addresses (Hp Procurve switches). We could use client shortnames, but the client shortnames we record in the database are not unique, as they're used as the machine name in FQDN's (so the same shortname can exist across different domains). We could use Pcket-Src-Ip-Address , but as the IP address in the database in split into four fields (ip1,ip2,ip3,ip4) , one for each octet, it requires the address to be split using a regular expression, prior to querying (which is not exactly an ideal solution). Making the Row ID available would give us a Unique Identifier for a NAS , which could be used to query the database quickly and efficiently. If it's too much trouble, I can think of a few other ways to do the same thing, just this is the most efficient way. Thanks, Arran -- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900
Arran Cudbard-Bell wrote:
I was wondering if it was possible / easy , to make RowID available as the request attribute Client-Uniqueid.
If it can be returned from an SQL query, sure.
We could use Pcket-Src-Ip-Address , but as the IP address in the database in split into four fields (ip1,ip2,ip3,ip4) , one for each octet, it requires the address to be split using a regular expression, prior to querying (which is not exactly an ideal solution).
That's not hard to do, and doesn't take too much CPU time. Alan DeKok.
Alan DeKok wrote:
Arran Cudbard-Bell wrote:
I was wondering if it was possible / easy , to make RowID available as the request attribute Client-Uniqueid.
If it can be returned from an SQL query, sure.
It should be already with the default query.
We could use Pcket-Src-Ip-Address , but as the IP address in the database in split into four fields (ip1,ip2,ip3,ip4) , one for each octet, it requires the address to be split using a regular expression, prior to querying (which is not exactly an ideal solution).
That's not hard to do, and doesn't take too much CPU time.
No true, it's more reusing the information. I suppose I could great some VSA attributes called-station-ip-octet1, called-station-ip-octet2, etc. But doing it with the returned ID would be cleaner. PS, almost finished with the mac, just got to the software updates and stick xcode on it, else you won't be able compile anything :)
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
-- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900
Arran Cudbard-Bell wrote:
Alan DeKok wrote:
Arran Cudbard-Bell wrote:
This has only happened in the last month or so, I remember everything running fine before then.
What does "config.guess" say?
powerpc-apple-darwin8.9.0
The "configure" script sets -DDARWIN if config.guess says *darwin. If the "Make.inc" file has CFLAGS = .... -DDARWIN, then it *should* work.
CFLAGS = $(INCLUDE) -g -O2
Make output confirms --DDARWIN not passed to gcc at compile time.
Or, maybe it's a run-time linking issue.
Alan DeKok.
Hehe well done Alan !
Yep adding --DDARWIN to CFLAGS fixes it :) Just need to find out why it wasn't there in the first place.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
Steven Simon