Your message dated Thu, 6 Oct 2016 23:08:46 +0200
with message-id <410609ab-b066-b29a-5faf-07ce4d247...@balintreczey.hu>
and subject line Re: forked-daapd: does not recreate stuff in /var/cache after 
deletion
has caused the Debian Bug report #839686,
regarding forked-daapd: does not recreate stuff in /var/cache after deletion
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
839686: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839686
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: forked-daapd
Version: 24.1-1+b1
Severity: serious
Justification: Policy 9.1.1

After deleting /var/cache/forked-daapd, forked-daapd cannot start up
again because it fails to open the database.

forked-daapd seems to require its data files there, while the FHS
unmistakably states:

"Unlike /var/spool, the cached files can be deleted without data loss.
The data must remain valid between invocations of the application and
rebooting the system.

Files located under /var/cache may be expired in an application specific
manner, by the system administrator, or both. The application must
always be able to recover from manual deletion of these files (generally
because of a disk space shortage). No other requirements are made on the
data format of the cache directories."

Please note that while the below information states this is Raspbian, I
can assure that forked-daapd and all its dependencies on this system are
plain Debian armhf ☺.

-- System Information:
Distributor ID: Raspbian
Description:    Raspbian GNU/Linux testing (stretch)
Release:        testing
Codename:       stretch
Architecture: armv7l

Kernel: Linux 4.4.21-v7+ (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages forked-daapd depends on:
ii  adduser             3.115
ii  avahi-daemon        0.6.32-1
ii  libantlr3c-3.2-0    3.2-3
ii  libasound2          1.1.2-1
ii  libavahi-client3    0.6.32-1
ii  libavahi-common3    0.6.32-1
ii  libavcodec-extra57  7:3.1.3-1+b3
ii  libavfilter6        7:3.1.3-1+b3
ii  libavformat57       7:3.1.3-1+b3
ii  libavutil55         7:3.1.3-1+b3
ii  libc6               2.24-3
ii  libconfuse1         3.0+dfsg-2
ii  libcurl3-gnutls     7.50.1-1
ii  libevent-2.0-5      2.0.21-stable-2+b1
ii  libgcrypt20         1.7.3-1
ii  libgnutls30         3.5.4-2
ii  libgpg-error0       1.24-1
ii  libjson-c3          0.12.1-1
ii  libmxml1            2.10-1
ii  libplist3           1.12-3.1
ii  libprotobuf-c1      1.2.1-1+b1
ii  libsqlite3-0        3.14.2-1
ii  libswscale4         7:3.1.3-1+b3
ii  libunistring0       0.9.6+really0.9.3-0.1
ii  psmisc              22.21-2.1
ii  zlib1g              1:1.2.8.dfsg-2+b1

Versions of packages forked-daapd recommends:
ii  libavcodec-extra                       7:3.1.3-1
ii  libavcodec-extra57 [libavcodec-extra]  7:3.1.3-1+b3

forked-daapd suggests no packages.

-- Configuration Files:
/etc/forked-daapd.conf changed [not included]

-- no debconf information

--- End Message ---
--- Begin Message ---
Control: notfound -1 24.1-1+b1

Hi Dominik,

On Mon, 03 Oct 2016 23:23:26 +0200 Dominik George <n...@naturalnet.de> wrote:
> Package: forked-daapd
> Version: 24.1-1+b1
> Severity: serious
> Justification: Policy 9.1.1
> 
> After deleting /var/cache/forked-daapd, forked-daapd cannot start up
> again because it fails to open the database.
> 
> forked-daapd seems to require its data files there, while the FHS
> unmistakably states:
> 
> "Unlike /var/spool, the cached files can be deleted without data loss.
> The data must remain valid between invocations of the application and
> rebooting the system.
> 
> Files located under /var/cache may be expired in an application specific
> manner, by the system administrator, or both. The application must
> always be able to recover from manual deletion of these files (generally
> because of a disk space shortage). No other requirements are made on the
> data format of the cache directories."

I have tested unstable's forked-daapd and if I remove cache files they
get recreated but the directory structure is not.

IMO it is unreasonable to think that removing the whole
/var/cache/forked-daapd directory can be deleted and is expected to be
recreated because many services drop root privileges thus can't create
dirs in /var/cache:

total 64
drwxr-xr-x 16 root  root 4096 Oct  6 20:56 .
drwxr-xr-x 11 root  root 4096 Sep  5 23:27 ..
drwxr-xr-x  3 root  root 4096 Sep  7 14:08 app-info
drwxr-xr-x  3 root  root 4096 Oct  6 20:56 apt
drwxr-xr-x  2 root  root 4096 Sep  7 14:08 cracklib
drwxr-xr-x  2 root  root 4096 Oct  5 09:25 debconf
drwxr-xr-x  2 root  root 4096 Sep  5 23:28 dictionaries-common
drwxr-xr-x  2 root  root 4096 Sep  8 20:40 fontconfig
drwxr-xr-x  2 root  root 4096 Feb 22  2016 fonts
drwxr-xr-x  2 daapd root 4096 Oct  6 21:01 forked-daapd
drwxr-xr-x  2 root  root 4096 Aug 31 08:28 gdm
drwx------  2 root  root 4096 Oct  6 20:56 ldconfig
drwx--x--x  3 root  root 4096 Sep  7 15:39 lightdm
drwxr-sr-x 37 man   root 4096 Oct  6 21:00 man
drwxr-xr-x  3 root  root 4096 Sep  7 14:08 PackageKit
drwxr-xr-x  2 root  root 4096 Aug 15 11:17 realmd

In my interpretation of the FHS the _files_ can be removed and are
expected to be recreated, while _directory structures_ need to be kept
for applications to operate.

Cheers,
Balint

--- End Message ---

Reply via email to