[00:05:37] <wm-bot>	 !log tools.bash <bd808> Updated to ff8328d
[00:05:38] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.bash/SAL
[01:25:24] <Krinkle>	 legoktm: I see some task/patches around codesearch mention disk space concerns. Anything I can do to help with that? Do we need to reprovision to a larger? I guess nowadays we use detacheable volume, so maybe it can be resized or we can move from one mount to another and temporarily attach 2 or something?
[01:26:04] <legoktm>	 did it run out of space again?
[01:26:09] <Krinkle>	 no, not yet :)
[01:26:37] <Krinkle>	 but it seems there is hesitancy to add "a lot" more repos, which I've personally ignored several times already
[01:26:43] <Krinkle>	 but not sure how many times to do that.
[01:26:48] <Krinkle>	 https://grafana-labs.wikimedia.org/d/000000059/cloud-vps-project-board?orgId=1&var-project=codesearch&from=now-30d&to=now&var-server=codesearch8
[01:27:01] <Krinkle>	 18GB left, using ~36GB
[01:28:48] <legoktm>	 the main issue is that git repos get larger over time (duh) and said growth is multiplied by the number of search profiles the repo is indexed in. I personally wouldn't be hesitant in adding new repos as long as someone or some monitoring is keeping an eye on disk space
[01:29:03] <legoktm>	 I think the simplest and best option is to throw more disk space at it
[01:30:02] <legoktm>	 probably some upstream issues could be filed with hound like running `git gc` or redoing the initial shallow clone ocassionally
[01:32:33] <legoktm>	 (AFAIK WMCS is not short on disk space, and given the value of codesearch vs maintainer time, it seems reasonable to ask for more space)
[01:33:58] <AntiComposite>	 it's only short of disk space in the right places
[01:39:42] <wm-bb>	 <lucaswerkmeister> /me seconds the immense value of codesearch (as if there were any doubts about that ^^)
[03:04:21] <wm-bb>	 <xtexChooser> What's the difference between `login.toolforge.org` and `dev.toolforge.org`?
[03:04:55] <wm-bb>	 <xtexChooser> It seems to be the same SSH host.
[03:12:45] <AntiComposite>	 shouldn't be
[03:14:16] <AntiComposite>	 login.toolforge.org goes to tools-sgebastion-10, dev.toolforge.org is -11
[03:15:13] <AntiComposite>	 there's nothing significantly different between the two hosts, except that if you slow dev. down fewer people will complain immediately
[03:17:13] <wm-bb>	 <xtexChooser> e
[03:17:14] <wm-bb>	 <xtexChooser> thanks
[13:55:43] <wm-bb>	 <xtexChooser> I am deploying a continuous deployment. I tried to run a script directly on the tool account through SSH, but found that I could not enter the tool directory. What's going on?
[13:55:43] <wm-bb>	 <xtexChooser> ```
[13:55:45] <wm-bb>	 <xtexChooser> ssh login.toolforge.org become new-userbox-log bash -c "cd src && pwd"
[13:55:46] <wm-bb>	 <xtexChooser> /mnt/nfs/labstore-secondary-tools-home/xtex```
[13:57:16] <wm-bb>	 <lucaswerkmeister> add another set of quotes (i.e. `bash -c '"cd src && pwd"'`)
[13:57:19] <wm-bb>	 <lucaswerkmeister> because ssh is awesome
[14:01:11] <wm-bb>	 <xtexChooser> thanks
[14:01:56] <taavi>	 also use /data/project/<tool> instead of the /mnt/nfs/... patch, the latter one is an implementation detail
[14:02:47] <wm-bb>	 <xtexChooser> okay, thanks
[17:32:25] <Krinkle>	 I'm debugging a weird situation on labswiki around the "Redirect fixer" user
[17:32:27] <Krinkle>	 $ mwscript sql.php --wiki labswiki
[17:32:27] <Krinkle>	 > SELECT * FROM user WHERE user_name='Redirect fixer';
[17:32:32] <Krinkle>	 (
[17:32:32] <Krinkle>	     [user_id] => 31136
[17:32:33] <Krinkle>	     [user_name] => Redirect fixer
[17:32:42] <Krinkle>	 So this exists, clearly, and even has non-zero edits
[17:32:56] <Krinkle>	 $user = User::newFromName( 'Redirect fixer' );
[17:33:00] <Krinkle>	 > echo $user->getName();
[17:33:00] <Krinkle>	 Redirect fixer
[17:33:04] <Krinkle>	 > echo $user->isItemLoaded('id');
[17:33:04] <Krinkle>	 1
[17:33:08] <Krinkle>	 > echo $user->getId();
[17:33:08] <Krinkle>	 0
[17:33:11] <Krinkle>	 isRegistered(); false
[17:33:22] <Krinkle>	 hence addToDatabase() fails with a key conflict 
[17:35:29] <Krinkle>	 it seems when load() is lazily triggered, it ends up convinced the user doesn't exist and so is fully loaded / like an anon.
[17:35:37] <Krinkle>	 > SELECT * FROM actor WHERE actor_name='Redirect fixer';
[17:35:38] <Krinkle>	     [actor_id] => 14640
[17:35:38] <Krinkle>	     [actor_user] => 
[17:35:38] <Krinkle>	     [actor_name] => Redirect fixer
[17:36:23] <Reedy>	 Dont' we have User::newSystemUser( 'usernaname', [ 'steal' => true ] )
[17:36:25] <Reedy>	 for stuff like this
[17:36:40] <Krinkle>	 https://wikitech.wikimedia.org/wiki/Special:Contributions/Redirect_fixer
[17:36:46] <Krinkle>	 edits are not imported either
[17:37:02] <Krinkle>	 it seems like they were made as recnet as March 2022 in a way that acted as a named anon user somehow.
[17:39:05] <Krinkle>	 Reedy: looks like steal isn't effective either
[17:39:08] <Krinkle>	 gets fooled by the same bug
[17:43:44] <Krinkle>	 only 2 results for this query:
[17:43:57] <Krinkle>	 > SELECT * FROM actor WHERE actor_user IS NULL AND actor_name RLIKE '^[A-Z]' AND actor_name NOT LIKE '%>%' LIMIT 10;
[17:43:57] <Krinkle>	     [actor_id] => 14640    [actor_user] =>      [actor_name] => Redirect fixer
[17:43:57] <Krinkle>	     [actor_id] => 37817    [actor_user] =>      [actor_name] => Unknown user
[17:48:44] <Krinkle>	 Depending on whether the "bug" is the logic in User::load or the fact that such rows can be created in the first place - if we believe the former, then it was introduced in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/525605 where the case for load by 'name' was changed from using the `user` table to using the `actor` table as definitive and only source.
[18:09:57] <Krinkle>	 write up at T326431
[18:09:58] <stashbot>	 T326431: Some system users have invalid 'actor' database rows - https://phabricator.wikimedia.org/T326431
[18:10:43] <Krinkle>	 I'm going to fix labswiki manually for now