From: "Kevin Coffman" Subject: Re: [PATCH 2/3] Remove old logging implementation for idmapd and rework gssd and idmapd to use the new xlog logging infrastructure. Date: Tue, 11 Sep 2007 11:32:04 -0400 Message-ID: <4d569c330709110832s58b4e7f8n4aefbde162530cf3@mail.gmail.com> References: <1189459543.7914.16.camel@moss-terrapins.epoch.ncsc.mil> <1189515746.12340.4.camel@moss-terrapins.epoch.ncsc.mil> <4d569c330709110800g558b1fect5f84ea20e25efc7b@mail.gmail.com> <1189523208.12340.10.camel@moss-terrapins.epoch.ncsc.mil> <4d569c330709110824t60745764l3fc63a393d51b0b9@mail.gmail.com> <1189524230.12340.15.camel@moss-terrapins.epoch.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: nfsv4@linux-nfs.org, nfs@lists.sourceforge.net To: "David P. Quigley" Return-path: Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.92] helo=mail.sourceforge.net) by sc8-sf-list2-new.sourceforge.net with esmtp (Exim 4.43) id 1IV7ia-0005bx-Tu for nfs@lists.sourceforge.net; Tue, 11 Sep 2007 08:32:01 -0700 Received: from rv-out-0910.google.com ([209.85.198.185]) by mail.sourceforge.net with esmtp (Exim 4.44) id 1IV7ie-0003jp-T7 for nfs@lists.sourceforge.net; Tue, 11 Sep 2007 08:32:05 -0700 Received: by rv-out-0910.google.com with SMTP id g11so4651420rvb for ; Tue, 11 Sep 2007 08:32:04 -0700 (PDT) In-Reply-To: <1189524230.12340.15.camel@moss-terrapins.epoch.ncsc.mil> List-Id: "Discussion of NFS under Linux development, interoperability, and testing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: nfs-bounces@lists.sourceforge.net Errors-To: nfs-bounces@lists.sourceforge.net Yes, Here is sample output with the line accumlation re-enabled in printerr(): Sep 11 11:16:43 rock rpc.svcgssd[22225]: Sep 11 11:16:43 rock rpc.svcgssd[22225]: in_tok: Sep 11 11:16:43 rock rpc.svcgssd[22225]: length 490 Sep 11 11:16:43 rock rpc.svcgssd[22225]: Sep 11 11:16:43 rock rpc.svcgssd[22225]: 0000: 6082 01e6 0609 2a86 4886 f712 0102 0201 `.....*.H....... Sep 11 11:16:43 rock rpc.svcgssd[22225]: 0010: 006e 8201 d530 8201 d1a0 0302 0105 a103 .n...0.......... Sep 11 11:16:43 rock rpc.svcgssd[22225]: 0020: 0201 0ea2 0703 0500 2000 0000 a381 fa61 ........ ......a Sep 11 11:16:43 rock rpc.svcgssd[22225]: 0030: 81f7 3081 f4a0 0302 0105 a110 1b0e 4349 ..0...........CI Sep 11 11:16:43 rock rpc.svcgssd[22225]: 0040: 5449 2e55 4d49 4348 2e45 4455 a225 3023 TI.UMICH.EDU.%0# Sep 11 11:16:43 rock rpc.svcgssd[22225]: 0050: a003 0201 03a1 1c30 1a1b 036e 6673 1b13 .......0...nfs.. Sep 11 11:16:43 rock rpc.svcgssd[22225]: 0060: 726f 636b 2e63 6974 692e 756d 6963 682e rock.citi.umich. Sep 11 11:16:43 rock rpc.svcgssd[22225]: 0070: 6564 75a3 81b3 3081 b0a0 0302 0101 a103 edu...0......... Sep 11 11:16:43 rock rpc.svcgssd[22225]: 0080: 0201 18a2 81a3 0481 a09d 90d7 31a0 e661 ............1..a Sep 11 11:16:43 rock rpc.svcgssd[22225]: 0090: e698 f31c 1aa1 fd18 a9b0 706e 9e4c 36c4 ..........pn.L6. Sep 11 11:16:43 rock rpc.svcgssd[22225]: 00a0: 3391 0612 eab0 8c07 ea70 d087 98e6 ac94 3........p...... Sep 11 11:16:43 rock rpc.svcgssd[22225]: 00b0: a81c 205a ba10 0f46 2351 fbb5 12bd 67c8 .. Z...F#Q....g. Sep 11 11:16:43 rock rpc.svcgssd[22225]: 00c0: e7f5 627e 4b71 cd23 0fea c6e3 a6f3 d122 ..b~Kq.#......." Sep 11 11:16:43 rock rpc.svcgssd[22225]: 00d0: a58d 1556 6788 4f0c 908a 36b1 3569 1456 ...Vg.O...6.5i.V Sep 11 11:16:43 rock rpc.svcgssd[22225]: 00e0: 779e 3af7 ba6e afe9 c910 f502 a9f8 2a61 w.:..n........*a Sep 11 11:16:43 rock rpc.svcgssd[22225]: 00f0: a546 07c1 be5a c992 8597 d9a4 6940 18bb .F...Z......i@.. Sep 11 11:16:43 rock rpc.svcgssd[22225]: 0100: e10c 263f 6afb 1a3f ec58 a6c6 315a bd43 ..&?j..?.X..1Z.C Sep 11 11:16:43 rock rpc.svcgssd[22225]: 0110: 7486 903a 36ac 303b 6cd9 ffc0 d3ec 724f t..:6.0;l.....rO Sep 11 11:16:43 rock rpc.svcgssd[22225]: 0120: d7c4 da92 e1a1 33ab 8fa4 81be 3081 bba0 ......3.....0... Sep 11 11:16:43 rock rpc.svcgssd[22225]: 0130: 0302 0101 a281 b304 81b0 35cf 6330 7a2a ..........5.c0z* Sep 11 11:16:43 rock rpc.svcgssd[22225]: 0140: 91b4 591c 38a8 6d3c 9192 ad49 85e6 92d6 ..Y.8.m<...I.... Sep 11 11:16:43 rock rpc.svcgssd[22225]: 0150: 539f 2a3a c66a 6e09 c320 589d 0ec8 0cc5 S.*:.jn.. X..... Sep 11 11:16:43 rock rpc.svcgssd[22225]: 0160: c433 cdeb d259 79a2 6547 b0e8 21aa 0324 .3...Yy.eG..!..$ Sep 11 11:16:43 rock rpc.svcgssd[22225]: 0170: 4cc5 ab73 fd76 d3b7 f36b 1ffc d140 a163 L..s.v...k...@.c Sep 11 11:16:43 rock rpc.svcgssd[22225]: 0180: c3e1 b1bd 8f82 c47c a5d4 1bf1 7d09 9be6 .......|....}... Sep 11 11:16:43 rock rpc.svcgssd[22225]: 0190: 65dc 96d2 2bf4 cb5f 637a 6649 0221 1973 e...+.._czfI.!.s Sep 11 11:16:43 rock rpc.svcgssd[22225]: 01a0: 6379 9537 ee31 fa8b 43f1 fe12 3f50 4ea2 cy.7.1..C...?PN. Sep 11 11:16:43 rock rpc.svcgssd[22225]: 01b0: d426 70e3 59c8 1d1f 933b 0e5a 384d a681 .&p.Y....;.Z8M.. Sep 11 11:16:43 rock rpc.svcgssd[22225]: 01c0: 8399 6319 d1cc 1890 fe99 b78d 36f6 6d84 ..c.........6.m. Sep 11 11:16:43 rock rpc.svcgssd[22225]: 01d0: 4d3a d4f2 8da2 a3e0 bea7 1cea 77c0 1acd M:..........w... Sep 11 11:16:43 rock rpc.svcgssd[22225]: 01e0: 4d27 5bfb 5e07 7562 9ffd M'[.^.ub.. Sep 11 11:16:43 rock rpc.svcgssd[22225]: sname = nfs/rock.citi.umich.edu@CITI.UMICH.EDU Sep 11 11:16:43 rock rpc.svcgssd[22225]: DEBUG: serialize_krb5_ctx: lucid version! Sep 11 11:16:43 rock rpc.svcgssd[22225]: prepare_krb5_rfc1964_buffer: serializing keys with enctype 4 and length 8 Sep 11 11:16:43 rock rpc.svcgssd[22225]: doing downcall Sep 11 11:16:43 rock rpc.svcgssd[22225]: \x01000000 2147483647 -1 -1 0 krb5 \x000000000000000018a0b8bfb0cfb0002001be0078520508000000000000000087b2e6463f15f013090000002a864886f7120102020400000008000000b9f42c618a2a3bdc04000000080000004904dc917adacb2c Sep 11 11:16:43 rock rpc.svcgssd[22225]: sending null reply On 9/11/07, David P. Quigley wrote: > I am trying to figure out exactly what this function is doing. I think > it might be best to precalculate the length of the string needed to > convert this char * to hex and then use snprintf to build it here rather > than in the logging subsystem. What exactly is the data that we are > getting in via cp? Are we just getting a string of bytes that we want > printed in hex? > > Dave > > On Tue, 2007-09-11 at 11:24 -0400, Kevin Coffman wrote: > > On 9/11/07, David P. Quigley wrote: > > > Could you point me to the second in gssd that is doing this? It might be > > > better to use the print statements in a saner way. > > > > > > Dave > > > > Agreed. The cuprit is print_hexl() in svcgssd_proc.c, which currently > > calls printerr() multiple times. I'll look to see if I can find other > > instances that might be depending on the line acculation of printerr. > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs