From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: from tb-ob1.topicbox.com (tb-ob1.topicbox.com [64.147.108.173]) by inbox.vuxu.org (Postfix) with ESMTP id A87842E873 for ; Wed, 13 Nov 2024 21:37:29 +0100 (CET) Received: from tb-mx0.topicbox.com (tb-mx0.nyi.icgroup.com [10.90.30.73]) by tb-ob1.topicbox.com (Postfix) with ESMTP id E585D34DB9 for ; Wed, 13 Nov 2024 15:37:28 -0500 (EST) (envelope-from bounce.mM22431927e91148f8ec10306e.r81958daa-7202-11ef-bbf2-18142b2d11b0@illumos.bounce.topicbox.com) Received: by tb-mx0.topicbox.com (Postfix, from userid 1132) id E589C2A4FCF; Wed, 13 Nov 2024 15:37:28 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=lists.illumos.org; h=to :message-id:date:mime-version:content-type :content-transfer-encoding:list-help:list-id:list-post :list-subscribe:reply-to:subject:from:list-unsubscribe; s= dkim-1; t=1731530248; x=1731616648; bh=QSTb4vppd7/TioZG7yHBDVzxj yzWE2tSzY0oINUigYM=; b=lEnbopYXnPbHY9LCAxfzxhxLtet0H2m9A3PeB67yj I/DF4ZbZKp4N1vh8hPEyCYLDPTnxodMhCS/gkQugK9OWWnEg/e8mef/VNBViO4VL iIxmzBaHxWGSoMm58qOb4DWkQGgWKzTaX5zgRwxJPh3X576OsSxz2C+Lf+gWdmG/ 8k= To: illumos-developer Message-Id: <17315301830.17AcEdaC1.14794@composer.illumos.topicbox.com> Date: Wed, 13 Nov 2024 15:36:23 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=17315301831.9b70C3c8F.14794 Content-Transfer-Encoding: 7bit Topicbox-Policy-Reasoning: allow: sender is a member Topicbox-Message-UUID: f2afbea8-a1fe-11ef-a0f4-bad040decc0b Archived-At: =?UTF-8?B?PGh0dHBzOi8vaWxsdW1vcy50b3BpY2JveC5jb20vZ3JvdXBz?= =?UTF-8?B?L2RldmVsb3Blci9UYjNiMGMwYzZlMjc4NDNlYS1NMjI0MzE5MjdlOTExNDhm?= =?UTF-8?B?OGVjMTAzMDZlPg==?= List-Help: List-Id: "illumos-developer" List-Post: List-Software: Topicbox v0 List-Subscribe: Precedence: list Reply-To: illumos-developer Subject: [developer] Who to debug kernel for non-global zones From: "Carsten Grzemba via illumos-developer" List-Unsubscribe: , Topicbox-Delivery-ID: 2:illumos:a901537c-2aea-11e7-965f-d98f9f16e227:81958daa-7202-11ef-bbf2-18142b2d11b0:M22431927e91148f8ec10306e:1:cFgFH1yBIT3PonadbFCFQ5VxdR7SyxI6xU-M0Gn_55Q --17315301831.9b70C3c8F.14794 Date: Wed, 13 Nov 2024 15:36:23 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Because I try to debug a problem of SMB-server in non-global zone (https://= illumos.topicbox.com/groups/omnios-discuss/T7cad60d9192b5050/session-setup-= failed-ntstatusnetlogonnotstarted), I have a question. In non-global zones I can't use mdb for the kernel, I can work with mdb onl= y in global zone. Dtrace functionality is also limited to userland componen= ts, so I can kernel modules only inspect by Dtrace also only in the global = zone, right? I attempt to investigate a problem of communication between smbsrv kernel m= odule and smbd running in non-global zone. Kernel module smbsrv communicates with smbd via socket on /var/smb/lipc/smb= auth. Because smbd is running in non-gloale zone this socket path is should= be related to the zone filesystem.=20 I assume there is only one instance of smbsrv kernel module running.? If I investigate the problem with Dtrace in the globale zone I see that it = is searched for the socket path related to the globale zone, where is no sm= bd running. So I get errno =3D 2, if the socket path do not exists in the g= lobal zone or errno =3D 146, if the path exists but the smbd is not running= .=20 Who do the smbsrv kernel module knows that it has to contact the smbd socke= t in the non-global zone? Or is this only an observation problem because I do the Dtracing in the glo= bal zone? Many thanks for clarification. ------------------------------------------ illumos: illumos-developer Permalink: https://illumos.topicbox.com/groups/developer/Tb3b0c0c6e27843ea-= M22431927e91148f8ec10306e Delivery options: https://illumos.topicbox.com/groups/developer/subscription --17315301831.9b70C3c8F.14794 Date: Wed, 13 Nov 2024 15:36:23 -0500 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Because I try to debug a problem of SMB-server= in non-global zone (= https://illumos.topicbox.com/groups/omnios-discuss/T7cad60d9192b5050/sessio= n-setup-failed-ntstatusnetlogonnotstarted), I have a question.
In non-global zones I can't use mdb for the kernel, I can work with m= db only in global zone. Dtrace functionality is also limited to userland co= mponents, so I can kernel modules only inspect by Dtrace also only in the g= lobal zone, right?
I attempt to investigate a p= roblem of communication between smbsrv kernel module and smbd running in no= n-global zone.
Kernel module smbsrv co= mmunicates with smbd via socket on /var/smb/lipc/smbauth. Because smbd is r= unning in non-gloale zone this socket path is should be related to the zone= filesystem.
I assume there is only one instance of smbsrv= kernel module running.?
If I investigate the problem with = Dtrace in the globale zone I see that it is searched for the socket path re= lated to the globale zone, where is no smbd running. So I get errno =3D 2, = if the socket path do not exists in the global zone or errno =3D 146, if th= e path exists but the smbd is not running.
Who do the smbs= rv kernel module knows that it has to contact the smbd socket in the non-gl= obal zone?
Or is this only an observation problem because I= do the Dtracing in the global zone?

Many = thanks for clarification.
= --17315301831.9b70C3c8F.14794--