[ISSUE] upgrading blueman & docker fails "Directory not empty"

[ISSUE] upgrading blueman & docker fails "Directory not empty"

[linde12]

[-- Attachment #1: Type: text/plain, Size: 2456 bytes --]

New issue by linde12 on void-packages repository

https://github.com/void-linux/void-packages/issues/33815

Description:
I'm having multiple weird issues today. First of all blueman-manager stopped working (all of a sudden i was missing dependencies like `gi` and `cairo`) so i thought i'd reinstall after an upgrade. What i did was:

```sh
xbps-remove blueman
xbps-install -Syu
```

After this it would start updaing packages but get stuck at the following:
```
bluez-5.61_1: updating to 5.62_2 ...
bluez-5.62_2: unpacking ...
ERROR: bluez-5.62_2: [unpack] failed to extract file `./etc/sv/bluetoothd/log/supervise': Directory not empty
ERROR: bluez-5.62_2: [unpack] failed to extract files: Directory not empty
ERROR: bluez-5.62_2: [unpack] failed to unpack files from archive: Directory not empty
Transaction failed! see above for errors.
```

I thought that was a weird error because obviously that directory is not empty because i still have bluez installed. However i uninstalled bluez as well because i did not want to spend any more time on this, but now i am getting a similar error from the `moby` package which is telling me that `/etc/sv/docker/log/supervise` also isn't empty which, again, it obviously isn't since i've installed docker previously.

```
moby-20.10.6_1: updating to 20.10.9_2 ...
moby-20.10.9_2: unpacking ...
ERROR: moby-20.10.9_2: [unpack] failed to extract file `./etc/sv/docker/log/supervise': Directory not empty
ERROR: moby-20.10.9_2: [unpack] failed to extract files: Directory not empty
ERROR: moby-20.10.9_2: [unpack] failed to unpack files from archive: Directory not empty
Transaction failed! see above for errors.
```

I'm wondering if anyone can help me shed some light on this. Blueman stopped working overnight and now i'm getting all these errors so i've got no idea whats going on.

### System

* xuname:  
Certificate verification failed for /C=US/O=Internet Security Research Group/CN=ISRG Root X1
SSL_connect returned 1
Certificate verification failed for /C=US/O=Internet Security Research Group/CN=ISRG Root X1
SSL_connect returned 1
Void 5.13.19_1 x86_64 GenuineIntel uptodate rFFF
* package:  
  moby-20.10.6_2, bluez-5.62_2

### Expected behavior
blueman to not break out of nowhere & `xbps-install -Syu` to work.
### Actual behavior
`xbps-install -Syu` fails when upgrading previously installed packages related to services such as dockerd & bluetoothd

Re: upgrading blueman & docker fails "Directory not empty"

[Duncaen]

[-- Attachment #1: Type: text/plain, Size: 287 bytes --]

New comment by Duncaen on void-packages repository

https://github.com/void-linux/void-packages/issues/33815#issuecomment-954912219

Comment:
Disable the affected services,  and delete the `sv/$name/log/supervise` directories.

https://github.com/void-linux/void-packages/issues/32076

Re: [ISSUE] [CLOSED] upgrading blueman & docker fails "Directory not empty"

[linde12]

[-- Attachment #1: Type: text/plain, Size: 2459 bytes --]

Closed issue by linde12 on void-packages repository

https://github.com/void-linux/void-packages/issues/33815

Description:
I'm having multiple weird issues today. First of all blueman-manager stopped working (all of a sudden i was missing dependencies like `gi` and `cairo`) so i thought i'd reinstall after an upgrade. What i did was:

```sh
xbps-remove blueman
xbps-install -Syu
```

After this it would start updaing packages but get stuck at the following:
```
bluez-5.61_1: updating to 5.62_2 ...
bluez-5.62_2: unpacking ...
ERROR: bluez-5.62_2: [unpack] failed to extract file `./etc/sv/bluetoothd/log/supervise': Directory not empty
ERROR: bluez-5.62_2: [unpack] failed to extract files: Directory not empty
ERROR: bluez-5.62_2: [unpack] failed to unpack files from archive: Directory not empty
Transaction failed! see above for errors.
```

I thought that was a weird error because obviously that directory is not empty because i still have bluez installed. However i uninstalled bluez as well because i did not want to spend any more time on this, but now i am getting a similar error from the `moby` package which is telling me that `/etc/sv/docker/log/supervise` also isn't empty which, again, it obviously isn't since i've installed docker previously.

```
moby-20.10.6_1: updating to 20.10.9_2 ...
moby-20.10.9_2: unpacking ...
ERROR: moby-20.10.9_2: [unpack] failed to extract file `./etc/sv/docker/log/supervise': Directory not empty
ERROR: moby-20.10.9_2: [unpack] failed to extract files: Directory not empty
ERROR: moby-20.10.9_2: [unpack] failed to unpack files from archive: Directory not empty
Transaction failed! see above for errors.
```

I'm wondering if anyone can help me shed some light on this. Blueman stopped working overnight and now i'm getting all these errors so i've got no idea whats going on.

### System

* xuname:  
Certificate verification failed for /C=US/O=Internet Security Research Group/CN=ISRG Root X1
SSL_connect returned 1
Certificate verification failed for /C=US/O=Internet Security Research Group/CN=ISRG Root X1
SSL_connect returned 1
Void 5.13.19_1 x86_64 GenuineIntel uptodate rFFF
* package:  
  moby-20.10.6_2, bluez-5.62_2

### Expected behavior
blueman to not break out of nowhere & `xbps-install -Syu` to work.
### Actual behavior
`xbps-install -Syu` fails when upgrading previously installed packages related to services such as dockerd & bluetoothd

Re: upgrading blueman & docker fails "Directory not empty"

[linde12]

[-- Attachment #1: Type: text/plain, Size: 440 bytes --]

New comment by linde12 on void-packages repository

https://github.com/void-linux/void-packages/issues/33815#issuecomment-954916840

Comment:
> Disable the affected services, and delete the `sv/$name/log/supervise` directories.
> 
> #32076

Thank you for the super quick reply! I did as you said and i also had to delete the `/etc/sv/bluetoothd/supervise/` directory (note: no `/log/`) and after xbps-install was working. Thanks again!

Re: upgrading blueman & docker fails "Directory not empty"

[jchook]

[-- Attachment #1: Type: text/plain, Size: 249 bytes --]

New comment by jchook on void-packages repository

https://github.com/void-linux/void-packages/issues/33815#issuecomment-967640271

Comment:
How does XBPS update other running services without this error?

Why does this one have trouble updating?

Re: upgrading blueman & docker fails "Directory not empty"

[Duncaen]

[-- Attachment #1: Type: text/plain, Size: 948 bytes --]

New comment by Duncaen on void-packages repository

https://github.com/void-linux/void-packages/issues/33815#issuecomment-967661799

Comment:
In normal cases the supervise "directory" is actually a symlink pointing to something like `/run/runit/supervise.$service`, this is something we do in void and it avoids runit writing temporary stuff to the filesystem of `/etc`.

What happened to some services was due to a bug in `xbps-src` this symlink was not created for the log services whose run file was a symlink to something, in this case `vlogger`.
This bug was fixed and those packages now contain this symlink. But since they did not previously and runit created the supervise directory, which also was not tracked by xbps we run into this problem.
xbps does not recursively delete previously untracked files, so because this directory is untracked and contains files, manual intervention is required once, once for those 12 services iirc.

Re: upgrading blueman & docker fails "Directory not empty"

[Duncaen]

[-- Attachment #1: Type: text/plain, Size: 914 bytes --]

New comment by Duncaen on void-packages repository

https://github.com/void-linux/void-packages/issues/33815#issuecomment-967661799

Comment:
In normal cases the supervise "directory" is actually a symlink pointing to something like `/run/runit/supervise.$service`, this avoids runit writing temporary stuff to the filesystem at `/etc`.

What happened to some services was due to a bug in `xbps-src` this symlink was not created for the log services whose run file was a symlink to something, in this case `vlogger`.
This bug was fixed and those packages now contain this symlink. But since they did not previously and runit created the supervise directory, which also was not tracked by xbps we run into this problem.
xbps does not recursively delete previously untracked files, so because this directory is untracked and contains files, manual intervention is required once, once for those 12 services iirc.

Re: upgrading blueman & docker fails "Directory not empty"

[Duncaen]

[-- Attachment #1: Type: text/plain, Size: 920 bytes --]

New comment by Duncaen on void-packages repository

https://github.com/void-linux/void-packages/issues/33815#issuecomment-967661799

Comment:
In normal cases the supervise "directory" is actually a symlink pointing to something like `/run/runit/supervise.$service`, this avoids runit/runsv writing temporary stuff to the filesystem at `/etc`.

What happened to some services was due to a bug in `xbps-src` this symlink was not created for the log services whose run file was a symlink to something, in this case `vlogger`.
This bug was fixed and those packages now contain this symlink. But since they did not previously and runit created the supervise directory, which also was not tracked by xbps we run into this problem.
xbps does not recursively delete previously untracked files, so because this directory is untracked and contains files, manual intervention is required once, once for those 12 services iirc.

Re: upgrading blueman & docker fails "Directory not empty"

[Duncaen]

[-- Attachment #1: Type: text/plain, Size: 898 bytes --]

New comment by Duncaen on void-packages repository

https://github.com/void-linux/void-packages/issues/33815#issuecomment-967661799

Comment:
In normal cases the supervise "directory" is actually a symlink pointing to something like `/run/runit/supervise.$service`, this avoids runit/runsv writing temporary stuff to the filesystem at `/etc`.

Due to a bug in `xbps-src` the `supervise` symlink was not created for the log services whose run file was a symlink to something, in this case `vlogger`.

This bug was fixed and those packages now contain this symlink. But since they did not previously and runit created the supervise directory, which also was not tracked by xbps we run into this problem.
xbps does not recursively delete previously untracked files, so because this directory is untracked and contains files, manual intervention is required once, once for those 12 services iirc.

Re: upgrading blueman & docker fails "Directory not empty"

[Duncaen]

[-- Attachment #1: Type: text/plain, Size: 898 bytes --]

New comment by Duncaen on void-packages repository

https://github.com/void-linux/void-packages/issues/33815#issuecomment-967661799

Comment:
In normal cases the supervise "directory" is actually a symlink pointing to something like `/run/runit/supervise.$service`, this avoids runit/runsv writing temporary stuff to the filesystem at `/etc`.

Due to a bug in `xbps-src` the `supervise` symlink was not created for the log services whose run file was a symlink to something, in this case `vlogger`.

This bug was fixed and those packages now contain the symlink.
But since they did not previously and runit created the supervise directory, which also was not tracked by xbps we run into this problem.
xbps does not recursively delete previously untracked files, so because this directory is untracked and contains files, manual intervention is required once, once for those 12 services iirc.

Re: upgrading blueman & docker fails "Directory not empty"

[Duncaen]

[-- Attachment #1: Type: text/plain, Size: 897 bytes --]

New comment by Duncaen on void-packages repository

https://github.com/void-linux/void-packages/issues/33815#issuecomment-967661799

Comment:
In normal cases the supervise "directory" is actually a symlink pointing to something like `/run/runit/supervise.$service`, this avoids runit/runsv writing temporary stuff to the filesystem at `/etc`.

Due to a bug in `xbps-src` the `supervise` symlink was not created for the log services whose run file was a symlink to something, in this case `vlogger`.

This bug was fixed and those packages now contain the symlink.
But since they did not previously and runit created the supervise directory, which also was not tracked by xbps we run into this problem.
xbps does not recursively delete previously untracked files, so because this directory is untracked and contains files, manual intervention is required once for those ~12 packages affected.

Re: upgrading blueman & docker fails "Directory not empty"

[jchook]

[-- Attachment #1: Type: text/plain, Size: 186 bytes --]

New comment by jchook on void-packages repository

https://github.com/void-linux/void-packages/issues/33815#issuecomment-967705121

Comment:
Brilliant, thanks a lot for the explanation.