The test (in nixos/tests/xmpp/ejabberd.nix) doesn't seem to work anymore, but that's true on master with or without this PR.
So if you want to fix it, that would be really cool. We can probably merge this either way.

Thank you for your feedback and for pointing me to the failing test (for any onlookers, here is the log of the failing test). :-) I had a quick look. The test looks reasonable enough and I cannot really fathom why it should fail.

Perhaps it's just because ejabberd is too slow to create the .erlang.cookie file? If so, we should give it some more slack by adding directly after line 253 of the test the following instruction:

server.sleep(15)

Unfortunately I cannot test this proposal, as I don't have access to any machine on which the flavor of qemu used by the test suite works.

Ah, that's a different unrelated failure. Which might be fixed by a sleep in there, yes.
What I'm talking about is the client failing like this.

What's weird is that it works in the prosody test, which calls the exact same client code.

Aha! 8aea528 is probably at fault then. The test works again when reverting it at least. @NinjaTrappeur could you maybe look into this? Seems like the ejabberd test might not be configured for some of the features this is trying to test now.

Hey!

The test does not seems to enable mod_disco nor mod_upload_http. The issue is coming from there.

I'm having a look at it.

PS: Ofborg can now run the VM tests, you probably want to setup passthru.tests for this package to let the CI run those. It'll be simpler to see stuff breaking in the future. See

After quite a bit of mud fighting with Ejabberd, I did not managed to setup mod_upload_http for this test. I suspect we'd need a proper TLS setup for the test. I'm not 100% sure about that though, the logs are pretty scarce. I guess somebody actually using Ejabbered would be a better candidate to fix that: I never used this software.

In the meantime, I wrote a small patch allowing us to disable the http_upload check for the Ejabbered test. I took advantage of this to add the passthru attribute I was talking about in the previous post.

I can't push anything to this branch, @iblech, could you apply the patch by running:

curl "https://github.com/NinjaTrappeur/nixpkgs/commit/deb1bcf3b221d2e626085b36d7da7e4647880448.patch" | git am

Thanks to both of you for picking up this issue! :-) NinjaTrappeur, I applied your patch, thanks for the taking the effort and making it extra-convenient for me!

You're welcome :)

Interesting, looks like ofborg is experiencing the same cookie issue you were seeing on hydra: https://logs.nix.ci/?key=nixos/nixpkgs.90462&attempt_id=4491813c-4b62-4904-8daf-4cf3ef7ec73e. That's weird, I do not experience that on my machine.

You can now run the test on ofborg by pushing to this branch (see the ejabberd.passthru.tests check), I'll let you find a workaround for that :)

[Edit]: the ARM test succeeded: https://github.com/NixOS/nixpkgs/pull/90462/checks?check_run_id=782114907. Looks like a flakiness issue. You're probably right regarding the delay.

Question: do we have a way to trigger a systemd target when the service is ready to receive some requests? That'll be a better fix as it would make sure we won't be subject to any flakyness in the future, regardless of the service boot time.

Hm, very interesting!

First I just pushed sleep(15), to see whether this actually makes the issue go away.

Then regarding a more robust solution: I was under the impression that wait_for_unit waits till the unit is in "active" state. But apparently ejabberd creates the cookie file only after systemd believes the unit to be active... Perhaps the correct fix would actually amend the systemd unit to create a placeholder cookie file before starting up ejabberd?

20.07 is out now + the fix in #97526 seems nicer than just disabling upload. The other parts of this PR, e.g. the passthru.tests and bump are still relevant, though.