Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#75201 - [curl] Version 7.84.1-1 Fails with error 12 when running pacman

Attached to Project: Arch Linux
Opened by Alexandre Bury (gyscos) - Thursday, 30 June 2022, 14:53 GMT
Last edited by Christian Hesse (eworm) - Friday, 08 July 2022, 21:20 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Christian Hesse (eworm)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 7
Private No



I have a local script to run pacman (and a few other update processes) in tmux panels. It was working fine until curl 7.84 was released. Since then, the pacman process systematically fails with the error:
error: curl returned error 12 from transfer
error: failed to synchronize all databases (unexpected error)

This is my (simplified) update script:

tmux new-session -d -s up
tmux split-window -v

tmux select-pane -t 0

tmux select-pane -t 0
tmux send-keys 'sudo pacman -Syy --noconfirm' C-m
tmux attach -t up

(Note that I have `sudo` set to allow pacman without password, which means pacman starts immediately in the script, without a potential delay from typing the password.)

With curl 7.84.0-1 installed, this systematically fails.
A few actions can prevent this failure:
- After downgrading to curl 7.83.1-1, I cannot reproduce the issue. After upgrading back to 7.84.0-1, the issue is back.
- If I add a delay longer than ~0.3s before the update, it also removes the issue. If the delay is too short (~0.1), the issue is back. With a delay of ~0.2, the issue is random.
- If I manually run the command, it works fine (most likely because it takes me more than 0.2s to run the command manually)
- If I update the script to not split the window, the issue also disappears.

This makes me think that the issue is caused by some race condition between the pacman process using libcurl and maybe the shell (zsh) initializing in the other panel. This zsh process is most likely doing all sort of stuff when initializing, but I would _hope_ that being separate processes, they would not interact like that.

This happens with an empty `~/.zshrc`. I had `grml-zsh-config` installed, but this still happens after I uninstall it.

Additional info:
* package version(s): pacman 6.0.1-5, tmux 3.3_a-2,
* The shell configured is zsh.
* link to upstream bug report, if any
This task depends upon

Closed by  Christian Hesse (eworm)
Friday, 08 July 2022, 21:20 GMT
Reason for closing:  Fixed
Additional comments about closing:  curl 7.84.0-2
Comment by Alexandre Bury (gyscos) - Thursday, 30 June 2022, 15:02 GMT
Note that apparently error 12 should be `CURLE_FTP_ACCEPT_TIMEOUT`? But I don't use FTP mirrors, only HTTPS.
Comment by Thomas Weißschuh (t-8ch) - Sunday, 03 July 2022, 14:57 GMT
As pacman is using the curl_multi interface it should probably be CURLM_UNRECOVERABLE_POLL (12)
Comment by Thomas Weißschuh (t-8ch) - Sunday, 03 July 2022, 15:06 GMT
Looks to be intentional new behaviour:
Comment by Thomas Weißschuh (t-8ch) - Sunday, 03 July 2022, 16:09 GMT
I *think* the problem is that pacman gets a SIGWINCH when the terminal window is resized. Because of this the call to poll() inside libcurl returns with EINTR and that is not handled correctly:
Comment by Thomas Weißschuh (t-8ch) - Sunday, 03 July 2022, 16:25 GMT Comment by Radu Potop (wooptoo) - Friday, 08 July 2022, 06:30 GMT
Getting the same error with pacman, log attached.
Comment by Christian Hesse (eworm) - Friday, 08 July 2022, 07:08 GMT
Thanks for catching this!
Can you please verify the curl 7.84.0-2 fixes this?
Comment by Radu Potop (wooptoo) - Friday, 08 July 2022, 07:30 GMT
I've updated curl as you advised and will watch out for this error. It doesn't _always_ happen from my experience. So I guess if it doesn't show up for a week or so then it's fixed for good.
Comment by Alexandre Bury (gyscos) - Friday, 08 July 2022, 14:13 GMT
I can confirm that my issues consistently disappears with curl 7.84.0-2. Thanks a lot!