Translating with DrWatson… this can take a few seconds the first time.
This is a genuine, complex translation. DrWatson protects commands, error codes, and log output while naturally translating the surrounding text. It’s translated once and saved.
Mark Scranton asked where sql_uid in syssqltrace is mapped to users and why user-level tracing still showed other users. Art Kagel said sql_uid is the OS user id, found for example by grepping /etc/passwd. For clients with a user id and password it comes from the matching local login, or the template user for mapped users. Kerberos was unknown and the second question got no answer.
Auto-generated by Claude from the posts below — may be imperfect; read the full thread.
Mark Scranton — source: IBM Community (ConnectedCommunity.org) Informix forum
Two questions:
1. I've used sqltrace for many years but have one area that I can't get clear ... sql_uid mapping to users via sql (not SS, OAT or HQ). I capture via a scheduler task the content of sysmaster:syssqltrace to sysadmin:mon_syssqltrace. sql_uid equates to a number and what I'm looking for is where these numbers are mapped. I know they correlate with syssessions, but what about users that don't have a session in syssessions?
2. I've turned on sqltrace at the "user" level and then added a user, let's say "skippy" to the user list. But I still am getting other users as well (agreed - this may be leftovers but my trace buffer duration is 5 secs so I doubt it). I may be getting the order of ops wrong since I've typically used SS or OAT for this over the years.
------------------------------
Thanks!
Mark Scranton
The Mark Scranton Group
mark@markscranton.com
------------------------------
↪ replying to Mark Scranton
Art Kagel — source: IBM Community (ConnectedCommunity.org) Informix forum
Mark:
You are overthinking this one. The sql_uid is the OS user id for the connected user:
informix@Elezar-II:~$ dbaccess sysmaster -
> select * from syssqltrace where sql_database = 'art';sql_id 65
sql_address 1501114952
sql_sid 90
sql_uid 1000
sql_stmttype 1
sql_stmtname DATABASE
sql_finishtime 1679412473
sql_begintxtime 1210465378
sql_runtime 0.00246567244
...
art@Elezar-II:~$ id
uid=1000(art) gid=1000(art) groups=
1000
(
art),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),122(lpadmin),133(lxd),134(sambashare),1001(informix)
------------------------------
Art S. Kagel, President and Principal Consultant
ASK Database Management Corp.
www.askdbmgt.com
------------------------------
↪ replying to Art Kagel
Mark Scranton — source: IBM Community (ConnectedCommunity.org) Informix forum
Thanks Art. I haven't "overthinked" (sic) anything since uh, yesterday.
So for windows client or a web app coming in with a connection string/passwd embedded - where does UID come from in those cases?
Any thoughts on Q#2 n original thread? May just be a syntax issue ... if so, nevermind, I'll work through it eventually.
Thanks!
------------------------------
Thanks!
Mark Scranton
The Mark Scranton Group
mark@markscranton.com
------------------------------
↪ replying to Mark Scranton
Art Kagel — source: IBM Community (ConnectedCommunity.org) Informix forum
Mark:
For clients connecting with a user id & pwd the server or trusted connection the user has to have a local login with the same user name. The engine does a getuser() call to validate and gets the uid from there. For mapped users, the uid will that of the local template user. All regardless of whether the client is running on Linux/Unix or Windows. If Kerberos or other authentication was used, I don't know where the uid would be coming from or how you would look it up. For Linux/Unix based servers, for most uid's just grep /etc/passwd:
art@Elezar-II:~$ grep 1000 /etc/passwd
------------------------------
Art S. Kagel, President and Principal Consultant
ASK Database Management Corp.
www.askdbmgt.com
------------------------------
We use strictly necessary cookies to make this site work. With your
consent we’d also use optional cookies for analytics and marketing. You can accept all,
reject all, or choose. Read our Cookie Policy.