-
Notifications
You must be signed in to change notification settings - Fork 20
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
Simulatenous access issues - Deadlock found when trying to get lock; try restarting transaction #608
Comments
Hi, Thanks for this feedback. I've Never experienced that even if I agree that ansible is a pain to use with passhport apparently. Since I can't have an easy way to reproduce, Can you provide a tool to contact multiple target in the same Time or describe step by step how to achieve that with a fresh ansible install ? Thanks |
I can reproduce it with the following bash script. Ansible is not even necessary. #!/usr/bin/env bash
set -exuo pipefail
# Usage: hammer.sh [email protected] target-1 target-2 target-3 ...
BASTION="$1"
shift
for TARGET in "$@"; do
ssh -xT -o "BatchMode=yes" -o "ControlMaster=no" "$BASTION" "$TARGET" hostname &
done
wait Errors start to happen with 3 targets or more. |
@guillaume-perreal , do you use the apache server in place of the embeded server ? |
Yes we are using Apache with the WSGI interface. |
Describe the bug
I am using ansible to configure targets that are only accessible through passhport,
using the same user for all targets.
When accessing one target at a time, everything goes fine.
However, when accessing to several targets in parallel, connections start to fail randomly. I have tracked down the error to this message in passhportd logs :
According to what I have found (https://stackoverflow.com/questions/2332768/how-to-avoid-mysql-deadlock-found-when-trying-to-get-lock-try-restarting-trans), this might be related to the locking order of rows in the MySQL. I think multiple instances of passhportd try to access the same rows of the database in parallel and it somehow fails. This might be related to the SQL transaction isolation, as IIRC there are different kind of isolations, depending on the planned operation to the rows (read/write/etc...).
To Reproduce
Expected behavior
Accessing all targets simulatenously
The text was updated successfully, but these errors were encountered: