per Tim it can resume where it stopped. running it manually in screen now to see..

You can control batchsize and max lag for this maintenance script with default script parameter. Maybe it helps to set the batchsize from 100 to a lower number and try again.

Daniel: Is this the script that powers the wikidata cronjob (at least partially)? If so, is this bug resolved (enough)?

It is puppetized in: operations/puppet repo

./manifests/misc/maintenance.php

class misc::maintenance::refreshlinks

51 cron { "cron-refreshlinks-${name}":
52 command => "/usr/local/bin/mwscriptwikiset refreshLinks.php ${cluster}.dblist --dfn-only > /home/mwdeploy/refreshLinks/${name}.log 2>&1",

65 # add cron jobs - usage: <cluster>@<day of month> (these are just needed monthly) (note: s1 is temp. deactivated)
66 cronjob { ['s2@2', 's3@3', 's4@4', 's5@5', 's6@6', 's7@7']: }

<-- as you can see in line 66 above, it is not applied to "s1" which would be enwiki. So it is just running for all other clusters because it never worked for s1. How to make it work on s1, i don't know, sorry.

This bug is about enable the script on s1, but that needs a fix of the maintenance script, which is tracked under bug 42180

Change 199989 had a related patch set uploaded (by PleaseStand):
refreshLinks.php: Limit rows scanned per query in deleteLinksFromNonexistent()

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

Change 199989 merged by jenkins-bot:
refreshLinks.php: Limit rows scanned per query in deleteLinksFromNonexistent()

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

The above change is in 1.25wmf24, which has been deployed to all Wikipedias. There may still be some performance issues, though the script should now be able to run to completion.