Bug#694379: initscripts: Symlinking /dev/shm to /run/shm makes Oracle Database XE unable to start. Bind mount makes it work.
On 2012-12-18 00:08, Roger Leigh wrote: A fixed version of sysvinit has now been uploaded. Note that it's much simpler than the above patch. All you need to do is add an entry for /dev/shm in /etc/fstab as documented in fstab(5), i.e. tmpfs /dev/shm tmpfs nosuid,nodev,size=40%,mode=177700 and it will all just work. Note that /run/shm will then be linked to /dev/shm, so it won't preclude us switching the default to /run/shm down the line. Thank you, Roger. I've tested this. The result is that Oracle Database 11g XE works now happily over /dev/shm. Regards, Jozsef -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#694379: initscripts: Symlinking /dev/shm to /run/shm makes Oracle Database XE unable to start. Bind mount makes it work.
On Mon, Dec 10, 2012 at 11:34:47PM +, Roger Leigh wrote: On Mon, Dec 10, 2012 at 09:47:39PM +, Roger Leigh wrote: On Sun, Dec 09, 2012 at 05:24:50PM +0100, Jozsef Marton wrote: Thank you, Roger, for your comments. You're right that the test Oracle XE applies is badly broken. See details inline your comment below. This has not been reported to Oracle as Debian Linux is not a supported platform for running their Database product. (I will make a try reporting this.) Though I understand that dev/shm is an implementation detail, it was user for ages and would using bind mount would simplify Debian users' life when they intend to use Oracle Database. I'm attaching a patch[1] I have tested that makes this behaviour configurable in /etc/default/tmpfs leaving symlink as the default value. I hope that this can be intergated in Wheezy. Thanks very much for the patch. I'll look at merging this, or something very similar to it--there are some other details which also need taking care of. Preliminary patch is at http://anonscm.debian.org/gitweb/?p=users/rleigh/sysvinit.git;a=commitdiff;h=9be900ce3dc679f3f49b86b439b90f6937a159aa A fixed version of sysvinit has now been uploaded. Note that it's much simpler than the above patch. All you need to do is add an entry for /dev/shm in /etc/fstab as documented in fstab(5), i.e. tmpfs /dev/shm tmpfs nosuid,nodev,size=40%,mode=177700 and it will all just work. Note that /run/shm will then be linked to /dev/shm, so it won't preclude us switching the default to /run/shm down the line. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#694379: initscripts: Symlinking /dev/shm to /run/shm makes Oracle Database XE unable to start. Bind mount makes it work.
On Mon, Dec 10, 2012 at 11:34:47PM +, Roger Leigh wrote: tags 694379 + serious thanks On Mon, Dec 10, 2012 at 09:47:39PM +, Roger Leigh wrote: On Sun, Dec 09, 2012 at 05:24:50PM +0100, Jozsef Marton wrote: Thank you, Roger, for your comments. You're right that the test Oracle XE applies is badly broken. See details inline your comment below. This has not been reported to Oracle as Debian Linux is not a supported platform for running their Database product. (I will make a try reporting this.) Though I understand that dev/shm is an implementation detail, it was user for ages and would using bind mount would simplify Debian users' life when they intend to use Oracle Database. I'm attaching a patch[1] I have tested that makes this behaviour configurable in /etc/default/tmpfs leaving symlink as the default value. I hope that this can be intergated in Wheezy. Thanks very much for the patch. I'll look at merging this, or something very similar to it--there are some other details which also need taking care of. Preliminary patch is at http://anonscm.debian.org/gitweb/?p=users/rleigh/sysvinit.git;a=commitdiff;h=9be900ce3dc679f3f49b86b439b90f6937a159aa This fits in with the existing script logic, and will simply mount the tmpfs on /dev/shm rather than /run/shm if RAMSHM_ON_DEV_SHM=yes. Note that this is currently not tested, so it's not ready for use yet. And (note to me), needs to default RAMSHM=yes if RAMSHM_ON_DEV_SHM=yes since there's no underlaying /run to fall back on. We don't use a bind mount because with this approach it's firstly not needed, and also because bind mounts don't play well in chroot environments. (Another note to me: check chroot upgrade logic in case /run/shm is hardcoded in the maintainer scripts.) With some further additions and testing, the current patch for this is here: http://anonscm.debian.org/gitweb/?p=users/rleigh/sysvinit.git;a=commitdiff_plain;h=f208974e295f187238d2ef6831ebc35d72b3c7de If you'd like to try this out, I'd be grateful for any feedback. If you would prefer prebuilt packages for testing, just let me know, and I'll make them available for download. Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#694379: initscripts: Symlinking /dev/shm to /run/shm makes Oracle Database XE unable to start. Bind mount makes it work.
On Sun, Dec 09, 2012 at 05:24:50PM +0100, Jozsef Marton wrote: Thank you, Roger, for your comments. You're right that the test Oracle XE applies is badly broken. See details inline your comment below. This has not been reported to Oracle as Debian Linux is not a supported platform for running their Database product. (I will make a try reporting this.) Though I understand that dev/shm is an implementation detail, it was user for ages and would using bind mount would simplify Debian users' life when they intend to use Oracle Database. I'm attaching a patch[1] I have tested that makes this behaviour configurable in /etc/default/tmpfs leaving symlink as the default value. I hope that this can be intergated in Wheezy. Thanks very much for the patch. I'll look at merging this, or something very similar to it--there are some other details which also need taking care of. Regarding the actual bug in Oracle, which is basically requiring the Mounted on field to be /dev/shm, this will break whenever /dev/shm is a symlink or not the root of a mountpoint. No guarantees have ever been made about this, so while we have exposed the bug by changing to a symlink, the actual bug which needs fixing is in Oracle. If you do file a bug with Oracle, which I would strongly encourage, please could you point them to the fstatvfs(3) system call, which is what df uses internally. This will give them access to the size, free space, filesystem type etc. Essentially everything you'd want out of the df output. They have the option of using statvfs(2) on /dev/shm, or fstatvfs(2) on any open file in /dev/shm. The latter is advisable, due to /dev/shm being an implementation detail; they should be using shm_open(3) in order to open files here, which would make fstatvfs(2) the preferred choice. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#694379: initscripts: Symlinking /dev/shm to /run/shm makes Oracle Database XE unable to start. Bind mount makes it work.
tags 694379 + serious thanks On Mon, Dec 10, 2012 at 09:47:39PM +, Roger Leigh wrote: On Sun, Dec 09, 2012 at 05:24:50PM +0100, Jozsef Marton wrote: Thank you, Roger, for your comments. You're right that the test Oracle XE applies is badly broken. See details inline your comment below. This has not been reported to Oracle as Debian Linux is not a supported platform for running their Database product. (I will make a try reporting this.) Though I understand that dev/shm is an implementation detail, it was user for ages and would using bind mount would simplify Debian users' life when they intend to use Oracle Database. I'm attaching a patch[1] I have tested that makes this behaviour configurable in /etc/default/tmpfs leaving symlink as the default value. I hope that this can be intergated in Wheezy. Thanks very much for the patch. I'll look at merging this, or something very similar to it--there are some other details which also need taking care of. Preliminary patch is at http://anonscm.debian.org/gitweb/?p=users/rleigh/sysvinit.git;a=commitdiff;h=9be900ce3dc679f3f49b86b439b90f6937a159aa This fits in with the existing script logic, and will simply mount the tmpfs on /dev/shm rather than /run/shm if RAMSHM_ON_DEV_SHM=yes. Note that this is currently not tested, so it's not ready for use yet. And (note to me), needs to default RAMSHM=yes if RAMSHM_ON_DEV_SHM=yes since there's no underlaying /run to fall back on. We don't use a bind mount because with this approach it's firstly not needed, and also because bind mounts don't play well in chroot environments. (Another note to me: check chroot upgrade logic in case /run/shm is hardcoded in the maintainer scripts.) Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#694379: initscripts: Symlinking /dev/shm to /run/shm makes Oracle Database XE unable to start. Bind mount makes it work.
Thank you, Roger, for your comments.
You're right that the test Oracle XE applies is badly broken. See
details inline your comment below.
This has not been reported to Oracle as Debian Linux is not a supported
platform for running their Database product. (I will make a try
reporting this.)
Though I understand that dev/shm is an implementation detail, it was
user for ages and would using bind mount would simplify Debian users'
life when they intend to use Oracle Database.
I'm attaching a patch[1] I have tested that makes this behaviour
configurable in /etc/default/tmpfs leaving symlink as the default value.
I hope that this can be intergated in Wheezy.
[1]: 20121209_lib_init_mount-functions_configurable_devshm_bindmount.patch
On 2012-11-30 00:09, Roger Leigh wrote:
On Thu, Nov 29, 2012 at 11:04:25PM +, Roger Leigh wrote:
On Thu, Nov 29, 2012 at 10:14:51PM +, Roger Leigh wrote:
On Sun, Nov 25, 2012 at 11:45:48PM +0100, Jozsef Marton wrote:
How is Oracle testing for the presence of /dev/shm? Their check is
obviously broken, but it would be helpful to know what exactly they
are doing. strace would be useful here.
strace showed the following check and result reagrdless of being
/dev/shm a bind mount or symlink to /run/shm. So until this, everything
is working with the new configuration.
stat(/dev/shm, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=60, ...}) = 0
Later on, after passing checks of /dev/shm, the following pattern comes
up in strace:
shmget(IPC_PRIVATE, 4194304, 0660) = 425984
shmat(425984, 0, 0x8000 /* SHM_??? */) = -1 EACCES (Permission denied)
shmctl(425984, IPC_RMID, 0) = 0
shmget(IPC_PRIVATE, 4096, IPC_CREAT|IPC_EXCL|0660) = 458752
shmat(458752, 0, 0) = ?
open(/dev/shm/ora_XE_458752_0, O_RDWR|O_CREAT|O_SYNC, 0660) = 9
ftruncate(9, 4194304) = 0
close(9)= 0
open(/dev/shm/ora_XE_458752_1, O_RDWR|O_CREAT|O_SYNC, 0660) = 9
ftruncate(9, 4194304) = 0
close(9)= 0
shmdt(0x7f8070a24000) = 0
They use the O_SYNC flag with open which is not available for shm_open.
Maybe it is not even necessary on tmpfs, but this would lead far from
our current issue.
The thing which most broken is between the stat and the first shmget
call, and is as follows:
To see the available shm size, Oracle check for the output of
/bin/df -k /dev/shm.
Being /dev/shm a symlink to /run/shm, the following is returned as df is
smart enough to follow symlink:
read(9, Filesystem 1K-blocks Used Available Use% Mounted on\ntmpfs
1572864 0 1572864 0% /run/shm\n, 4096) = 112
Being /dev/shm a bind mount os /run/shm, the following is returned:
read(9, Filesystem 1K-blocks Used Available Use% Mounted on\ntmpfs
1572864 0 1572864 0% /dev/shm\n, 4096) = 112
Note that df resolve the symlink before producing its output, and this
fools Oracle XE. By writing a wrapper around /bin/df to handle /bin/df
-k /dev/shm call on exception path without resolving symlink,
everything is fine again, Oracle is working properly.
For peoples searching for this Oracle error on Debian Wheezy, I'm also
attaching a wrapper[2] for df that can also be used to circumvent this
problem.
NOTE that this wrapper is not meant to be included in Debian. I wrote it
only to proof my concept that df output fooled Oracle XE.
To use this, first
# mv /bin/df /bin/df.real
then save the attached df script as /bin/df, then
# chown root:root df
# chmod 755 /bin/df
[2]: df_wrapper_to_handle_-k_devshm_exceptionally.sh
Best regards,
Jozsef
--- lib_init_mount-functions.sh.orig 2012-07-01 15:30:00.0 +0200
+++ lib_init_mount-functions.sh 2012-12-09 16:37:58.241399349 +0100
@@ -353,7 +353,10 @@ run_migrate ()
# them yet. If the user explicitly mounted a filesystem here,
# it will be cleaned out, but this would happen later on when
# bootclean runs in any case.
- if [ ! -L $OLD ] [ -d $OLD ] ; then
+ # If SHM is forced to be bind mounted to /run/shm in /etc/default/tmpfs
+ # /dev/shm is not removed, so later bind mount will be initiated.
+ if [ ! -L $OLD ] [ -d $OLD ]
+ ( [ $OLD != /dev/shm ] || [ ${SHM_BINDMOUNT_TO_DEV_SHM:-no} != yes ] ) ; then
rm -fr $OLD 2/dev/null || true
fi
--- etc_default_tmpfs.orig 2012-08-11 19:30:40.0 +0200
+++ etc_default_tmpfs 2012-12-09 16:56:41.693108624 +0100
@@ -31,3 +31,12 @@
# Mount tmpfs on /tmp if there is less than the limit size (in kiB) on
# the root filesystem (overriding RAMTMP).
#TMP_OVERFLOW_LIMIT=1024
+
+
+# Mount /dev/shm as a bind mount of /run/shm instead of symlinking to it.
+# Badly broken software (eg. see Debian Bug #694379) might depend on
+# being shared memory mounted to the hardcoded path /dev/shm.
+# Default: no
+# Set to yes to force bind mount.
+#SHM_BINDMOUNT_TO_DEV_SHM=no
+SHM_BINDMOUNT_TO_DEV_SHM=yes
Bug#694379: initscripts: Symlinking /dev/shm to /run/shm makes Oracle Database XE unable to start. Bind mount makes it work.
On Sun, Nov 25, 2012 at 11:45:48PM +0100, Jozsef Marton wrote: After the transition to /run/shm from its previous location at /dev/shm, a symlink was created for compatibility reasons: /dev/shm - /run/shm In this configuration Oracle Database 11g XE refuses to start with the following error message: ORA-00845: MEMORY_TARGET not supported on this system Bind mounting /run/shm to /dev/shm does the trick: Oracle starts properly. How is Oracle testing for the presence of /dev/shm? Their check is obviously broken, but it would be helpful to know what exactly they are doing. strace would be useful here. The odd thing is, even when it's a symlink, % test -d /dev/shm % echo $? 0 a simple test for if it's a directory is fine. A test for if it's a tmpfs is fine. So what exactly are Oracle's criteria for checking if /dev/shm is to be used? Oracle Database XE is not in Debian, but there could be other packages I'm unaware of that also suffer from /dev/shm being a symlink. I doubt this is the case. Most software will use the standard shm_open et. al. calls, and everything will just work. /dev/shm is an internal implementation detail of the POSIX shared memory support in glibc. No software should be directly looking at /dev/shm (or /run/shm) at all. Any software doing this is badly broken. SUS/POSIX does not mention /dev/shm. A quick patch to make /dev/shm be bind mount of /run/shm is attached. It would be inevitable better to allow users to configure this behavior, but I'm not sure if there is already a file where this configuration option could be added. If you could point me to the right place I would be happy to patch this to be configurable leaving the symlinking the default behavior. This type of low-level implementation detail is not something anyone should need to configure explicitly--it should just work. The existing configurable parameters are in /etc/default/tmpfs; see tmpfs(5). While it would be technically possible to add an additional option, we'll need to know more about the problem first; i.e. understand exactly why Oracle is failing here. /run/shm has been the default for around 1½ years, and this is the first issue reported with it. Unfortunately, we're several months into the wheezy code freeze. It might be possible to fix this issue once we understand the problem and have a tested patch for it, but there are no guarantees this late into the freeze. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#694379: initscripts: Symlinking /dev/shm to /run/shm makes Oracle Database XE unable to start. Bind mount makes it work.
On Thu, Nov 29, 2012 at 10:14:51PM +, Roger Leigh wrote:
On Sun, Nov 25, 2012 at 11:45:48PM +0100, Jozsef Marton wrote:
After the transition to /run/shm from its previous location at /dev/shm, a
symlink was created for compatibility reasons:
/dev/shm - /run/shm
In this configuration Oracle Database 11g XE refuses to start with the
following error message:
ORA-00845: MEMORY_TARGET not supported on this system
Bind mounting /run/shm to /dev/shm does the trick: Oracle starts properly.
How is Oracle testing for the presence of /dev/shm? Their check is
obviously broken, but it would be helpful to know what exactly they
are doing. strace would be useful here.
Just to double check that everything is working correctly, this is
a simple test program:
--
#include sys/mman.h
#include sys/stat.h
#include fcntl.h
#include stdio.h
#include errno.h
#include stdlib.h
#include string.h
#include unistd.h
void fail(const char *msg, const char *err)
{
fprintf(stderr, E: %s: %s\n, msg, err);
exit(1);
}
int main(void)
{
int fd = shm_open(test_shm, O_CREAT|O_RDWR|O_EXCL|O_TRUNC, 0600);
if (fd 1)
fail(shm_open, strerror(errno));
if (write(fd, Test\n, 4) 0)
fail(write, strerror(errno));
if (shm_unlink(test_shm) 0)
fail(shm_unlink, strerror(errno));
exit(0);
}
--
Build with
% gcc -o test test.c -lrt -g3 -Wall -Wextra
Trace:
% strace ./test 21 | tail -n 4
open(/dev/shm/test_shm, O_RDWR|O_CREAT|O_EXCL|O_TRUNC|O_NOFOLLOW|O_CLOEXEC,
0600) = 3
write(3, Test, 4) = 4
unlink(/dev/shm/test_shm) = 0
exit_group(0) = ?
As you can see, this opens test_shm, i.e. /dev/shm/test_shm,
writes some data into it, and unlinks it. If you remove the unlink
call and look in /run/shm (or /dev/shm), you'll see test_shm there.
This is just to demonstrate that the fundamental calls of the POSIX
SHM interface are indeed working correctly with /run/shm and /dev/shm
as a symlink to /run/shm. It's all working entirely correctly.
Has this issue been brought up with Oracle? Given that this looks like
a bug in Oracle, that's really where the problem needs to be fixed.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#694379: initscripts: Symlinking /dev/shm to /run/shm makes Oracle Database XE unable to start. Bind mount makes it work.
On Thu, Nov 29, 2012 at 11:04:25PM +, Roger Leigh wrote:
On Thu, Nov 29, 2012 at 10:14:51PM +, Roger Leigh wrote:
On Sun, Nov 25, 2012 at 11:45:48PM +0100, Jozsef Marton wrote:
After the transition to /run/shm from its previous location at /dev/shm,
a symlink was created for compatibility reasons:
/dev/shm - /run/shm
In this configuration Oracle Database 11g XE refuses to start with the
following error message:
ORA-00845: MEMORY_TARGET not supported on this system
Bind mounting /run/shm to /dev/shm does the trick: Oracle starts properly.
How is Oracle testing for the presence of /dev/shm? Their check is
obviously broken, but it would be helpful to know what exactly they
are doing. strace would be useful here.
Just to double check that everything is working correctly, this is
a simple test program:
--
#include sys/mman.h
#include sys/stat.h
#include fcntl.h
#include stdio.h
#include errno.h
#include stdlib.h
#include string.h
#include unistd.h
void fail(const char *msg, const char *err)
{
fprintf(stderr, E: %s: %s\n, msg, err);
exit(1);
}
int main(void)
{
int fd = shm_open(test_shm, O_CREAT|O_RDWR|O_EXCL|O_TRUNC, 0600);
if (fd 1)
Typo. Should be 0 of course.
--
.''`. Roger Leigh
: :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#694379: initscripts: Symlinking /dev/shm to /run/shm makes Oracle Database XE unable to start. Bind mount makes it work.
Package: initscripts Version: 2.88dsf-32 Severity: important Tags: patch After the transition to /run/shm from its previous location at /dev/shm, a symlink was created for compatibility reasons: /dev/shm - /run/shm In this configuration Oracle Database 11g XE refuses to start with the following error message: ORA-00845: MEMORY_TARGET not supported on this system Bind mounting /run/shm to /dev/shm does the trick: Oracle starts properly. Oracle Database XE is not in Debian, but there could be other packages I'm unaware of that also suffer from /dev/shm being a symlink. A quick patch to make /dev/shm be bind mount of /run/shm is attached. It would be inevitable better to allow users to configure this behavior, but I'm not sure if there is already a file where this configuration option could be added. If you could point me to the right place I would be happy to patch this to be configurable leaving the symlinking the default behavior. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages initscripts depends on: ii coreutils 8.13-3.2 ii debianutils 4.3.2 ii libc6 2.13-35 ii lsb-base4.1+Debian8 ii mount 2.20.1-5.2 ii sysv-rc 2.88dsf-32 ii sysvinit-utils 2.88dsf-32 Versions of packages initscripts recommends: ii e2fsprogs 1.42.5-1 ii psmisc 22.19-1 initscripts suggests no packages. -- no debconf information --- lib_init_mount-functions.sh.orig 2012-07-01 15:30:00.0 +0200 +++ /lib/init/mount-functions.sh 2012-09-03 12:36:00.138599600 +0200 @@ -353,7 +353,7 @@ run_migrate () # them yet. If the user explicitly mounted a filesystem here, # it will be cleaned out, but this would happen later on when # bootclean runs in any case. - if [ ! -L $OLD ] [ -d $OLD ] ; then + if [ ! -L $OLD ] [ -d $OLD ] [ $OLD != /dev/shm ] ; then rm -fr $OLD 2/dev/null || true fi
