Tag Info

Hot answers tagged

6

Packaged application have their own locations, typicall under /usr/ or /var/lib/, with executables (or links to them) under /bin/ or /usr/bin/ For self-compiled or self-written application, you can use /usr/local/bin/ for the executables and /usr/<appname>/ for the application itself (or its asset files). Some more (albeit somewhat outdated) ...


3

This is covered in the Debian Policy Manual. According to the section on configuration files, generally acceptable locations are /etc or /etc/{app_name}.


3

This is the problem with raidz1 (and also RAID5). If the data on the disk changes but no drive fault occurs to let ZFS or the RAID controller know which drive caused the error, then it can't know which drive is correct. With raidz2 (and higher) or RAID6, you get a quorum of drives that can decide which drive to ignore for reconstruction. Your only solution ...


2

No, a zero bytes file is not an indication of file system corruption. Likely symptoms of file system corruption include: Error messages from the file system showing up on the kernel log I/O errors when trying to read/write on the file system Bogus file attributes, owner, sizes, names showing up in directory listings. The most reliable way to identify ...


2

You may be bumping into the limitation of 16 bit ports (65536).


1

As mentioned above by shodanshok /usr/local is a good place to store an application that is not a package (deb, rpm). Hovewer, if you would rather have your app in one directory (instead of /usr/local/etc for config files, /usr/local/bin for executables), you can place it in /opt directory. This is often the directory of choice in case of apps that come with ...


1

nowadays, git-annex has its own solutions for this problem. you can use: git annex info --fast * ...to get actual disk usage (and more) from the files directly from git-annex. it can also operate on remote repositories, which is very useful: git annex info --fast --not --in here . ... would give you the amount of data that is not in the current ...


1

Resolution This issue was discussed with Red Hat Engineering under Private Bug 702085, but was not able to be repaired within the RHEL 5 product lifecycle. Red Hat Product Management have elected not to repair this issue within RHEL 6 for the following reasons: Customer exposure to this issue is not significant. This behaviour is ...


1

Responding to some of your question, in order: You can use mount -o remount,nr_inodes=NUM /run/lock in your application startup script (in case it's run with uid=0). It should also be safe to add relevant line to /etc/fstab, but haven't tested. Separation makes some sense here, as in case of filling up all inodes will not interfere with the rest of the ...


1

Short answer: the culprit was the way we deleted old backup directories, namely rsyncing an empty directory. Now we use: find "${old?}" -delete This is also fast and avoids the problem. Longer answer: in fact, the runs which took exceptionally long occurred absolutely deterministic. We always keep a number of, say n, backups and delete the oldest one ...



Only top voted, non community-wiki answers of a minimum length are eligible