Jorg, Your advice was spot on: "kioskuseradm show" revealed that, even though I have 400 utkus defined in /etc/passwd, the output listed only 200.
Do I have to delete the extra 200 kiosk accounts on 01 and re-run "kioskuseradm extend"? Just run the "extend" command? Background As I stated in the original problem description, I set these SRSs up with an original allocation of 200 accounts. Later, I used "kioskuseradm extend" to add 200 more [after first moving some recently-created accounts to different UIDs so they didn't block my desired contiguous range for utku]. The reason I didn't think it was account-related was that, at the time, all sessions were being directed to this SRS and I have 279. So I reasoned that, if it was a kiosk allocation problem, I should have seen it when I crossed the 200 threshold. I guess not all of the 279 were connecting to the fully-loaded SRS I ran "kioskuseradm show" on a different FOG and it displayed the correct # of kiosk sessions. I'm pretty sure I did the same "kioskuseradm extend" command on both systems but obviously either I did not or something went wrong on the second system. I guess part of my problem was when I ran the "extend" command, my only method of verification was to look at /etc/passwd. Oh, and another interesting observation: the FOG with the problem has 2 servers. 01 shows only 200 kiosk accounts. But 02 shows the correct 400. ?? Thanks! Scott -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jörg Barfurth Sent: Tuesday, January 22, 2013 3:28 AM To: SunRay-Users mailing list Subject: EXT :Re: [SunRay-Users] "All kiosk accounts are in use" Am 18.01.13 21:47, schrieb Nishimura, Scott L (ESS): > Both servers have 400 kiosk accounts provisioned. It's been this way > for months. No recent changes except server1 was patched the previous > week. > > The UIDs are allocated in a contiguous range. > > I set up the servers with 200 accounts originally. Then, other > programs took the next available UIDs so I had to move their UIDs to > #s below my utkus so I could expand the group to 400 in a contiguous > range. So if there was a UID problem, I would have expected it to > occur at 201, not 279. > BTW: With a local outage (restart all kiosk sessions on the host), you can move and resize (grow or shrink) the kiosk uid range to an arbitrary place in the uid space. If you create a 'guard' account at kiosk-base-uid + 10000, you can prevent that the range is restricted by other programs accidentally. > Prstat showed no unusual loading. I did not seem to be > resource-bound. > > This is my typical patching scenario: offload all sessions to > server1 while doing Live Update and patching the ABE on server2. > Reboot, enable connections on server2 and repeat for server1. So I > always end up with one SRS handling all sessions and I've never had a > problem before. > > This time, TCs started seeing > > Error starting kiosk session: All kiosk accounts are in use. > > /var/opt/SUNWut/log/messages showed > > Jan 18 03:30:58 bctlsu01 dtlogin[11111]: [ID 476860 user.error] > pam_kiosk: pam_sm_authenticate: Allocating a Kiosk user failed: > Account is currently reserved > That is the error related to the preceding message. And yes, this would indicate that all kiosk accounts are bound to a display number. > Jan 18 03:08:01 bctlsu01 utauthd: [ID 702911 user.info] read_config_file(): > Could not open config file (/etc/opt/SUNWut/utadmin.conf), error 24 > Jan 18 03:08:01 bctlsu01 utauthd: [ID 702911 user.info] ut_openDsConnection: > Could not read config file (/etc/opt/SUNWut/utadmin.conf) > Jan 18 03:08:01 bctlsu01 utauthd: [ID 501976 user.error] Crypto: FAIL to > check key status: Cannot connoct to Data Store: File access error > Jan 18 03:08:01 bctlsu01 utauthd: [ID 926371 user.info] Worker28 UNEXPECTED: > Crypto: Failed to update key status. > Jan 18 03:08:01 bctlsu01 utauthd: [ID 638413 user.info] Worker28 NOTICE: > Denying 155.104.201.253: key validation failed > That occurs much earlier in the connection lifecycle. If it reoccurs, it is a serious problem that would prevent any client from connecting. If this is a recurring problem, open a case with Oracle support. If it occurred only once, it may be some sort of file system fluke. The failing kiosk session (20 minutes later) got past this, apparently without a hitch. > I can't tell whether it was trying to allocate the same kiosk account > or whether it was trying different ones. > > So was it ultimately a data store error or a kiosk session allocation > error? Since I had plenty of unused kiosk sessions, I'm leaning > towards the data store issue. > The "Error starting kiosk session: All kiosk accounts are in use." is a purely kiosk message and has no direct relation to the data store. To view your kiosk account configuration look at # /opt/SUNWkio/bin/kioskuseradm show To check the status of kiosk session allocation, look at # /opt/SUNWkio/bin/kioskuseradm status If that shows surprising numbers of session in use, use # /opt/SUNWkio/bin/kioskuseradm status -v to get full detail and use output of # /opt/SUNWut/sbin/utsession -p or # /opt/SUNWut/bin/utwho -a to correlate the display numbers to SRS sessions. If there is a significant number of kiosk accounts that are bound to a display/session that does not exist any more, then you should also open a case with Oracle support. > The utadmin.conf file in question is now readable but I didn't try > when the problem was occurring. Even though that error occurred > first in the log, I'm inclined to think it was a symptom, not a > cause. > Without more data store and kiosk error messages that change the picture, I'm inclined to think it is completely unrelated. > Searching for the full string > > "FAIL to check key status" crypto > > Yielded no results. > Where did you search? Best Regards - Jörg Barfurth -- Jörg Barfurth http://blogs.oracle.com/joergb Disclaimer: I am employed by Oracle. The statements and opinions expressed here are my own and do not necessarily represent those of Oracle Corporation. _______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users _______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users
