Page MenuHomePhabricator

Temporarily unassign 'transcode-reset' user right from Commons autoconfirmed and sysop groups
Closed, DeclinedPublic

Description

Due to abusive transcode resets, the queue has increased from low 2k+ the day before yesterday, to 2800+ yesterday, then 3100+ now.

Many of the transcodes will run for 8 hours for nothing, as they will fail due to timeout.

The issue was discussed on IRC and I issued a note at T153488#2920246. However the increase in queue did not stop. @Dereckson said there are no server logs to check to find out who's doing this. As a short term measure, the right shall be unassigned to prevent further abuse.

For emergency uses, the right shall be kept for confirmed user group. Admins can assign the group to themselves or other users in emergency.

Related Objects

Event Timeline

Change 330835 had a related patch set uploaded (by Zhuyifei1999):
Unassign 'transcode-reset' from Commons autoconfirmed and sysop groups

https://gerrit.wikimedia.org/r/330835

@Dereckson said he will take care of SWAT.

Dzahn removed a subscriber: Dzahn.Jan 6 2017, 2:17 AM

(For the record, this has been announced by @Revent at Village Pump)

So what is going on with the transcoding servers? I went to the page to see what is transcoding and it seems to be halted from taking anything from the queue.

So what is going on with the transcoding servers?

Possible side effect of T154780

tomasz added a subscriber: tomasz.EditedJan 7 2017, 10:33 PM

For how long is this planned to be in operation?

Revent added a comment.Jan 8 2017, 6:43 AM

@Jasonanaggie There are other issues with the special page not correctly showing some tasks that are actually 'running'. Transcodes are being run, and the queue is going down noticeably, it's just that a significant number of the remaining ones are multi-GB files.

Revent added a comment.Jan 8 2017, 8:59 PM

@tomasz I think that it's important to prevent anything but 'new uploads' being thrown in the queue at least until it's actually completely caught up, and it's hard to estimate because it will depend on just how long the remaining ones take to be run. The queue is now down to 1393 transcodes, but it's also effectively been sorted by all this to many of the worst 'time intense' transcodes.... I have seen probably close to a dozen in there that are over 3GB in size. They will probably fail, but they need time to do so to get out the the queue.

None of this will help much, however, if we merely re-enable the ability for huge numbers of transcodes to just be thrown back in again.

@Dereckson When do you think this can be deployed?

Queue seems to be clear now. If the button does not get abuse again in a few days, feel free to close this as declined.

matmarex closed this task as Declined.Jan 11 2017, 5:02 PM

Please reopen if needed. T154737: Add entries to Special:Log regarding use of transcode resets is the long-term solution.

Change 330835 abandoned by Dereckson:
Unassign 'transcode-reset' from Commons autoconfirmed and sysop groups

Reason:
Not needed anymore.

https://gerrit.wikimedia.org/r/330835