cannot delete non-empty directory: php-1.29.0-wmf.3 messages on 'scap sync' on mwdebug1002
Closed, ResolvedPublic

Description

I am guessing there are some permission issues here?

addshore@mwdebug1002:~$ scap pull
14:02:22 Copying to mwdebug1002.eqiad.wmnet from deployment.eqiad.wmnet
14:02:22 Started rsync common
cannot delete non-empty directory: php-1.29.0-wmf.4/cache/l10n
cannot delete non-empty directory: php-1.29.0-wmf.4/cache/l10n
cannot delete non-empty directory: php-1.29.0-wmf.4/cache
cannot delete non-empty directory: php-1.29.0-wmf.4/cache
cannot delete non-empty directory: php-1.29.0-wmf.4
cannot delete non-empty directory: php-1.29.0-wmf.3/cache/l10n
cannot delete non-empty directory: php-1.29.0-wmf.3/cache/l10n
cannot delete non-empty directory: php-1.29.0-wmf.3/cache
cannot delete non-empty directory: php-1.29.0-wmf.3/cache
cannot delete non-empty directory: php-1.29.0-wmf.3
14:02:33 Finished rsync common (duration: 00m 10s)

Related Objects

Addshore created this task.Feb 2 2017, 2:16 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 2 2017, 2:16 PM
Addshore moved this task from Backlog to Watching on the User-Addshore board.

Looks like these messages still appear today during EU swat!

mmodell edited projects, added Scap; removed scap2.Feb 10 2017, 6:22 PM
mmodell closed this task as Resolved.Feb 10 2017, 6:31 PM
mmodell claimed this task.
Addshore reopened this task as Open.Feb 13 2017, 2:23 PM

I just saw this again today in EU swat.

these are generally caused by some files owned by l10nupdate with the wrong ownership (not group writable) ... The solution would be to adjust the umask for the l10nupdate process.

thcipriani closed this task as Resolved.Feb 15 2017, 12:06 AM
thcipriani claimed this task.
thcipriani added subscribers: mmodell, thcipriani.

What's happening here is that we removed the wmf-1.29.0-wmf.{3,4} directory on tin; however rsync --delete does not have the permission to remove files on a remote machine that are owned by a different user (in this case l10nupdate).

To fix this, you can run: scap clean 1.29.0-wmf.3 from /srv/mediawiki-staging on tin which manually removes files from both the deployment hosts and targets.

Addshore moved this task from Watching to Done on the User-Addshore board.Feb 21 2017, 9:57 AM

Mentioned in SAL (#wikimedia-operations) [2017-02-23T14:42:31Z] <addshore> addshore@tin scap clean 1.29.0-wmf.6 && scap clean 1.29.0-wmf.7 (to remove warning on scap pull on mwdebug1002, T157030)