From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gandalf.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id 489D65A0270 for ; Thu, 6 Apr 2023 04:50:17 +0200 (CEST) Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4PsQvz6mzGz4xFp; Thu, 6 Apr 2023 12:50:07 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=201602; t=1680749407; bh=FLK3SDeyG/rUYJW06zkd/NNLEo7AdDwvIa+LBLrhyGA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=g/hYv//sxidYnrD4p2Aq4Y/474h8YiXMshNQFcVhKlorSorz+9xwjMb8QUTKzmy38 Uw3+8njpKIj8Lad0sEJZzs0PmnCr5SaCNEwTsX1Ksj1fW+8oCh3V2sS+wXsMlosWLt VOtwJj/2Lu14anlQtMeoaAzFV2uJSTeJ+9NTcOVo= Date: Thu, 6 Apr 2023 12:31:55 +1000 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH 04/14] nstool: Split some command line parsing and socket setup to subcommands Message-ID: References: <20230404014638.3225556-1-david@gibson.dropbear.id.au> <20230404014638.3225556-5-david@gibson.dropbear.id.au> <20230405135800.1c3705ca@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qg8TPxpmH0fVjB8d" Content-Disposition: inline In-Reply-To: <20230405135800.1c3705ca@elisabeth> Message-ID-Hash: Q4KNMBGHFJ4KFCTXPM7C6JNOUMCJEWYP X-Message-ID-Hash: Q4KNMBGHFJ4KFCTXPM7C6JNOUMCJEWYP X-MailFrom: dgibson@gandalf.ozlabs.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --qg8TPxpmH0fVjB8d Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 05, 2023 at 01:58:00PM +0200, Stefano Brivio wrote: > On Tue, 4 Apr 2023 11:46:28 +1000 > David Gibson wrote: >=20 > > This will make it easier to differentiate the options to those commands > > further in future. > >=20 > > Signed-off-by: David Gibson > > --- > > test/nstool.c | 102 +++++++++++++++++++++++++++++++++----------------- > > 1 file changed, 68 insertions(+), 34 deletions(-) > >=20 > > diff --git a/test/nstool.c b/test/nstool.c > > index 7e069b6..9ea7eeb 100644 > > --- a/test/nstool.c > > +++ b/test/nstool.c > > @@ -11,6 +11,7 @@ > > #include > > #include > > #include > > +#include > > #include > > #include > > #include > > @@ -37,19 +38,55 @@ static void usage(void) > > " terminate.\n"); > > } > > =20 > > -static void hold(int fd, const struct sockaddr_un *addr) > > +static int connect_ctl(const char * sockpath, bool wait) > > { > > + int fd =3D socket(AF_UNIX, SOCK_STREAM, PF_UNIX); > > + struct sockaddr_un addr =3D { > > + .sun_family =3D AF_UNIX, > > + }; > > int rc; > > =20 > > - rc =3D bind(fd, (struct sockaddr *)addr, sizeof(*addr)); > > + if (fd < 0) > > + die("socket(): %s\n", strerror(errno)); >=20 > Unrelated: it would be nice if die() added newlines eventually. Sure, but as you say unrelated. > > + > > + strncpy(addr.sun_path, sockpath, UNIX_PATH_MAX); > > + > > + do { > > + rc =3D connect(fd, (struct sockaddr *)&addr, sizeof(addr)); > > + if (rc < 0 && > > + (!wait || (errno !=3D ENOENT && errno !=3D ECONNREFUSED))) > > + die("connect() to %s: %s\n", sockpath, strerror(errno)); >=20 > A (1ms?) delay would be nice to have here -- it's almost a busyloop, > connect() fails fast. Yeah, I guess so. That's not new, it was already like that in "nsholder pid", so I think something to fix separately. > > + } while (rc < 0); > > + > > + return fd; > > +} > > + > > +static void cmd_hold(int argc, char *argv[]) > > +{ > > + int fd =3D socket(AF_UNIX, SOCK_STREAM, PF_UNIX); > > + struct sockaddr_un addr =3D { > > + .sun_family =3D AF_UNIX, > > + }; > > + const char *sockpath =3D argv[1]; > > + int rc; > > + > > + if (argc !=3D 2) > > + usage(); > > + > > + if (fd < 0) > > + die("socket(): %s\n", strerror(errno)); > > + > > + strncpy(addr.sun_path, sockpath, UNIX_PATH_MAX); > > + > > + rc =3D bind(fd, (struct sockaddr *)&addr, sizeof(addr)); > > if (rc < 0) > > - die("bind(): %s\n", strerror(errno)); > > + die("bind() to %s: %s\n", sockpath, strerror(errno)); > > =20 > > rc =3D listen(fd, 0); > > if (rc < 0) > > - die("listen(): %s\n", strerror(errno)); > > + die("listen() on %s: %s\n", sockpath, strerror(errno)); > > =20 > > - printf("nstool: local PID=3D%d local UID=3D%u local GID=3D%u\n", > > + printf("nstool hold: local PID=3D%d local UID=3D%u local GID=3D%u\n= ", > > getpid(), getuid(), getgid()); > > do { > > int afd =3D accept(fd, NULL, NULL); > > @@ -63,71 +100,68 @@ static void hold(int fd, const struct sockaddr_un = *addr) > > die("read(): %s\n", strerror(errno)); > > } while (rc =3D=3D 0); > > =20 > > - unlink(addr->sun_path); > > + unlink(sockpath); > > } > > =20 > > -static void pid(int fd, const struct sockaddr_un *addr) > > +static void cmd_pid(int argc, char *argv[]) > > { > > - int rc; > > + const char *sockpath =3D argv[1]; > > struct ucred peercred; > > socklen_t optlen =3D sizeof(peercred); > > + int fd, rc; > > =20 > > - do { > > - rc =3D connect(fd, (struct sockaddr *)addr, sizeof(*addr)); > > - if (rc < 0 && errno !=3D ENOENT && errno !=3D ECONNREFUSED) > > - die("connect(): %s\n", strerror(errno)); > > - } while (rc < 0); > > + if (argc !=3D 2) > > + usage(); > > + > > + fd =3D connect_ctl(sockpath, true); >=20 > I didn't spot this earlier, but... does it really make sense to wait in > cmd_pid(), also on ENOENT, rather than making 'hold' return only once > the socket is ready? So, this is a consequence of the fact that the holder doesn't move into the background itself - it just sits in the foreground until terminated. That means that the typical usecase puts it into the background from the shell with &, which in turn means that when we reach the next shell command the socket may not be ready - or not even created. One of the things I had in mind for a hypothetical "nstool unshare" would be to avoid this and have it background itself once the socket is ready. > I don't think it would be outrageous to have > 'nstool pid' failing if the holding process doesn't exist. >=20 > Admittely, I'm biased by the few hundreds of times I needed to > 'killall -9 nsholder' in the past months. :) So... I agree that's irritating, I've done it a similar number of times. However, I don't think that's really related to the question above - in my experience it's always been the holder process that's hung around, not something waiting on a holder. > > rc =3D getsockopt(fd, SOL_SOCKET, SO_PEERCRED, > > &peercred, &optlen); > > if (rc < 0) > > - die("getsockopet(SO_PEERCRED): %s\n", strerror(errno)); > > + die("getsockopet(SO_PEERCRED) %s: %s\n", > > + sockpath, strerror(errno)); > > =20 > > close(fd); > > =20 > > printf("%d\n", peercred.pid); > > } > > =20 > > -static void stop(int fd, const struct sockaddr_un *addr) > > +static void cmd_stop(int argc, char *argv[]) > > { > > - int rc; > > + const char *sockpath =3D argv[1]; > > + int fd, rc; > > char buf =3D 'Q'; > > =20 > > - rc =3D connect(fd, (struct sockaddr *)addr, sizeof(*addr)); > > - if (rc < 0) > > - die("connect(): %s\n", strerror(errno)); > > + if (argc !=3D 2) > > + usage(); > > + > > + fd =3D connect_ctl(sockpath, false); > > =20 > > rc =3D write(fd, &buf, sizeof(buf)); >=20 > Unrelated: a compound literal would make this more readable. Uh.. I don't see where a compound literal would even go here. --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --qg8TPxpmH0fVjB8d Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmQuLxQACgkQzQJF27ox 2GdM4xAAiPxAFlGhjoD75w10MB2wG7TcaUF7JJ4FQ7llxWB+lk9AEMm93Y56fWtm Rytfvid+WgBPJnGO5pR+OdQt+NFM1efYGs98yRqX2vhsiaNzhCDT26+ot1Fn2o+N GYOVhmF4EBifWknaf1yLQ6nIlPCokqziv9/tmuRA4RjeIqjDTB+BUC/cskQm+sWS vr2C+4Hq4njRSK2k2fyHdBkwc/HUzt40bQxXN8qVEyMfIu4YOFIcFR4QrkhiCWFO Rue9Aa+SKZ53XoQZkFJY4edlgZ7n+/82jhXifVBltAH+hwj0VL4cb0ShdfifZZKi JBGL3DguIHuYx9extjcr96GJp7FkTSo86mD0nAkabgNMzxL18mI6NT8FYvo+2Y7l 2ag2TIYpQXxpoxyMwLn6Ka/AqyYyb/wiuw80Ay0Hp60SFxhaMDVflueeWrolw5vB okqHCOd4oEPElWLalkO1c/G8uWA+digFh2nbszST9HctZX95z3Zm4dHtwx1M6RzW IDqN63Kc4n+WTXYZw2/+rcjOPEPne9pm+/bbkNe9RR7sQCuPuD7csEuFup06vH4w 5dMFpkd0n2j51+c7LWJit8BLlsGjMGd7veFtVJNRrsPj7eU4nzaqEngXdc+tTvh5 ye/WoZ8qObP2DhpRO8YxDe4QH1Oi1j6UU3emcKgaMKuW/egHKHw= =kNE/ -----END PGP SIGNATURE----- --qg8TPxpmH0fVjB8d--