On Wed, Jun 29, 2022 at 07:32:42AM -0400, Matt Barry wrote: > On Wed, 2022-06-29 at 11:13 +0200, Marc Haber wrote: > > On Tue, Jun 28, 2022 at 01:34:23PM -0400, Matt Barry wrote: > > > Good call. I've attached a minimal POC, which works in manual > > > testing, > > > but automated testing is tricky and there may be edge cases. (This > > > test is blocking; NB (erroring out) might be easier to test, but > > > which > > > is the better UX?) > > > > A minimal test would be the test taking the lock, calling out to > > adduser > > and seeing whether it fails. The other side (testing whether adduser > > properly takes the lock) is probably harder. > > I was thinking the same thing; this too is easier to test if adduser's > behavior is non-blocking (ie. fail instead of wait). Is that the > desired response?
You're of course right, if we want to wait for the lock to become free (which probably is the sensible thing to do) the test is much harder. The only method I think about is introducing an internal option --delay which will sleep for a ten seconds or so after obtaining the lock, sending an adduser --delay into the background and checking how much wallclock time a foreground adduser will take while the background adduser is still running. Or we would have a diagnostic output "waiting for lock" and check for that. Not nice at all, but we could for example steal code from a daemon package such like openldap which does a lot of tests by invoking a daemon in the background and hurling test requests at it. Disclaimer: I don't know whether openldap's tests are written in perl. Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
