Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

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!
Tasklist

FS#17337 - {wiki} Confirmation email doesn't put into effect

Attached to Project: Arch Linux
Opened by Nekmo (nekmo) - Tuesday, 01 December 2009, 17:59 GMT
Last edited by Dan McGee (toofishes) - Thursday, 17 March 2011, 16:10 GMT
Task Type Bug Report
Category Web Sites
Status Closed
Assigned To Pierre Schmitz (Pierre)
Aaron Griffin (phrakture)
Thomas Bächler (brain0)
Dan McGee (toofishes)
Andrea Scarpino (BaSh)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Greetings.

I've tried to register in Arch Linux's Wiki ( http://wiki.archlinux.org/ ). Unfortunately, after several unsuccessful attemps, I couldn't do it. The register works properly, and I have received the confirmation e-mail. If I click on the first link, I can clearly see "Your e-mail address has now been confirmed.", but I'm still unable to edit wiki pages. ("You must confirm your e-mail address before editing pages. Please set and validate your e-mail address through your user preferences."). I also noticed that user changes on the options panel just don't work. I've already tried with 3 nicks, 3 emails, and 3 different passwords, but I still can't get it working.

Thank you for your time, and I hope you answer soon, cause I'm really excited about contributing in my fav. distribution's Wiki.

----- ESPAÑOL (España) ------
Título: "[WIKI-ARCH] Confirmación de email no pone en efecto"

Muy buenas.

He intentado registrarme en la Wiki de Archlinux ( http://wiki.archlinux.org/ ) pero tras varios intentos me ha sido imposible. El registro se realiza correctamente, y recibo el email de confirmación, confirmo mediante el primer enlace, y efectivamente se puede ver el mensaje "Your e-mail address has now been confirmed.", pero aún así sigo sin poder editar páginas del wiki ("You must confirm your e-mail address before editing pages. Please set and validate your e-mail address through your user preferences."). También he notado que los cambios efectuados en opciones no se realizan. He probado con 3 nicks, 3 emails y 3 contraseñas diferentes, todos los intentos han llevado a error.

Muchas gracias por vuestra paciencia, y espero vuestra contestación, pues estoy realmente ansioso de poder colaborar con la Wiki de mi distribución favorita.

Saludos.
This task depends upon

Closed by  Dan McGee (toofishes)
Thursday, 17 March 2011, 16:10 GMT
Reason for closing:  No response
Additional comments about closing:  Old bugs that aren't going anywhere.
Comment by Aaron Griffin (phrakture) - Tuesday, 01 December 2009, 18:41 GMT
I can confirm this (see the phraktest account)

As a side-note, gmail marked the email as spam. Unrelated, but interesting
Comment by Nekmo (nekmo) - Tuesday, 01 December 2009, 18:54 GMT
I have tried with these accounts:
- nekmo
- capitanquartz
- nintux

Thanks :)
Comment by Luciano Contartese (C4b3z0n) - Tuesday, 01 December 2009, 20:36 GMT
I'm having this problem too, account: C4b3z0n. I sent 3 confirmation mails and they didn't authorize the account, though it said that it did. I then changed my e-mail, tryed again, not working, same issue.
Comment by Pierre Schmitz (Pierre) - Wednesday, 02 December 2009, 17:02 GMT
I could confirm the problem; but I have no idea why this happens, so far.
Comment by Pierre Schmitz (Pierre) - Thursday, 03 December 2009, 20:03 GMT
I added some more guys, so you know what happened here in case of any failure. I tracked this problem down to the use of memcahced. Somehow the cache doesn't get updated etc..

For now I switched to APC for caching. According to Dan APC had caused problems (see http://bugs.php.net/bug.php?id=46025) I don't know if this problem is still valid though. In the meantime we have updated to new major versions of PHP and APC and switched from mod_php to fcgi.

We should monitor the servers behavior at least for one week before I consider this bug as "resolved".
Comment by Dan McGee (toofishes) - Thursday, 03 December 2009, 20:07 GMT
What the heck? Yes the problem is still valid, it will just not crash Apache anymore. APC for caching is a terrible idea as it is in-process only, so you lose a ton of caching across spawned processes and when they get shot after so many requests are made.

If you tracked this down to "the use of memcached", you did file a bug upstream with MediaWiki I assume? I'd love to help but the lack of detail here is not very good. Considering they (Wikimedia) use memcached heavily in production, I'm a bit skeptical here.
Comment by Pierre Schmitz (Pierre) - Thursday, 03 December 2009, 20:51 GMT
Sorry, maybe I didn't explain it clearly. At first this should be considered as a workaround for now. People had difficulties to login and editing pages, so my first goal was to get it working somehow.

APC is per process but we only have one php-fcgi process which launches some child processes. APC works fine here and all those children share one cache.

For now I have no more detailed information than that it works with memcached disabled and doesn#t with it enabled. It will take some time to setup a similar server locally and to reproduce this problem; I don't really want to debug this directly on the server.


EDIT: I fear you are right about the php process. I just saw that apache indeed launches several independent processes. But I guess this can be configured differently. E.g. I have set "max-procs" to 1 in lighttpd.
Comment by Pierre Schmitz (Pierre) - Thursday, 03 December 2009, 21:02 GMT
Another additional note: Do we have a rough idea since when this problem exists? I have found this in out pacman.log:

[2009-09-13 11:28] upgraded memcached (1.2.8-1 -> 1.4.1-1)
[2009-10-26 23:45] upgraded memcached (1.4.1-1 -> 1.4.2-1)
[2009-11-26 13:24] upgraded memcached (1.4.2-1 -> 1.4.3-1)
Comment by Dan McGee (toofishes) - Thursday, 03 December 2009, 22:10 GMT
Yeah, I was going to mention that memcached made the big jump from 1.2.X to 1.4.X just recently. That may play some role in this.

Perhaps on bug day this weekend someone can take a peek at this? I will try to be around and may hit up #memcached or #wikipedia or whatever the relevant channels are to see if anyone has an idea of what is going on here.
Comment by Dan McGee (toofishes) - Thursday, 25 February 2010, 03:03 GMT
I've taken a look at this a bit both tonight and last night and am not quite sure what is going on. I re-enabled memcached on gudrun and have created two test accounts; I can get neither to exhibit this behavior. Have we upgraded any other components lately, or what could have changed? If someone else would like to try to break it again while memcached is fully enabled, that would be awesome.
Comment by Dan McGee (toofishes) - Thursday, 25 February 2010, 03:31 GMT
I should also add I'm not convinced enabling APC "fixed" this bug; I simply think you had a greater chance of picking a thread that didn't share the same cache. I can't say that for certain however.

Loading...