Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

'cassandane smtpd' processes don't exit when cassandane(?) crashes #72

Open
elliefm opened this issue Jun 7, 2019 · 1 comment
Open

Comments

@elliefm
Copy link
Contributor

elliefm commented Jun 7, 2019

I mostly notice this when /dev/shm/cass fills up (with old logs) and then Cassandane crashes. Afterwards, I have to killall 'cassandane smtpd' to tidy up, otherwise future test runs get sporadic errors due to port numbers already being in use.

Interestingly, the other processes Cassandane starts up (all the cyrus masters, the fake notifyd, etc) seem to be tidied up correctly on this sort of failure. Not sure what the difference is, haven't looked, just throwing this up here so it's recorded somewhere.

@elliefm
Copy link
Contributor Author

elliefm commented Mar 17, 2021

This might be because the thing that we fork is itself a forking server...

Relatedly, I think we need to rip this out of Instance.pm and into its own file (like utils/fakeldapd and utils/fakesaslauthd), and either hook it up to be started by master (like those two), or fork/exec it properly. As it currently stands, we end up deep in some subclass of Net::Server but with the running test's entire memory space still mapped, too. If the child process exits via anything but POSIX::_exit (which it does, and we can't control), it goes and calls all the test's destructors, leaving a mess behind for nontrivial tests...

I have a nasty little workaround in Instance.pm that will make its destructor bail out if the calling pid is the wrong one, but that still only protects the Instances, not anything else...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant