while Installing oracle 11gr2 on oracle Linux 7. The prerequisite condition to test whether the OS kernel parameter "semmni" is failed with below error.
Please find the screenshot of it.
Below is the kernel parameters which are configured in the etc/sysctl.conf file.
fs.aio-max-nr = 1048576
fs.file-max = 6815744
kernel.shmall = 2097152
kernel.shmmax = 2147483648
kernel.shmmni = 4096
#semaphores: semmsl, semmns, semopm, semmni
kernel.sem = 250 256000 100 1024
net.ipv4.ip_local_port_range = 9000 65500
net.core.rmem_default=262144
net.core.rmem_max=4194304
net.core.wmem_default=262144
net.core.wmem_max=1048586
Any idea why it is failing?
You are missing the kernel.semmni=128.
Read the requirements here.
https://docs.oracle.com/cd/E11882_01/install.112/e24326/toc.htm#BHCGJCEA
I recommend you to install all requirements at once using the preinstall package. Find the link here:
https://blogs.oracle.com/linux/oracle-rdbms-server-11gr2-pre-install-rpm-for-oracle-linux-6-has-been-released
I just have the same problem. I checked my /proc/sys/kernel/sem and the values are exactly as its been mentioned in the Oracle document.
Plus, despite having all the packages, its still showing me FAILED when it check the packages.
It is fixable, you could just click the Fix button and execute the specified script to fix it.
Related
I followed the usage steps as per the example, after the second step of defining "conn" the script terminates and comes back to the command line without raising any errors o warnings or exception.
I am not able to identify what went wrong, has anyone faced this issue with jaydebeapi?
Sharing the libraries/environment details I am using and screenshot.
Example:
import jaydebeapi
conn = jaydebeapi.connect("org.hsqldb.jdbcDriver",
... "jdbc:hsqldb:mem:.",
... ["SA", ""],
... "/path/to/hsqldb.jar",) --------my script terminates at this step
curs = conn.cursor()
Environment:
Windows 10 64bit
Python 3.7.4
JayDeBeApi==1.1.1
JPype1==0.6.3
sasl==0.2.1
thrift==0.10.0
thrift-sasl==0.3.0
Jar = hive-jdbc-1.2.1-standalone.jar
Resolution is appreciated.
Are you using same (i.e. 64 bit) versions of programms? Reinstallation from python 32 to python 64 helped me with the same problem.
I have build environment to run code in a Docker container. One of the components is OpenMPI, which I think is the source of problem or manifest it.
When I run code using MPI I getting message,
Unexpected end of /proc/mounts line `overlay / overlay rw,relatime,lowerdir=/var/lib/docker/overlay2/l/NHW6L2TB73FPMK4A52XDP6SO2V:/var/lib/docker/overlay2/l/MKAGUDHZZTJF4KNSUM73QGVRUD:/var/lib/docker/overlay2/l/4PFRG6M47TX5TYVHKQQO2KCG7Q:/var/lib/docker/overlay2/l/4UR3OEP3IW5ZTADZ6OKT77ZBEU:/var/lib/docker/overlay2/l/LGBMK7HFUCHRTM2MMITMD6ILMG:/var/lib/docker/overlay2/l/ODJ2DJIGYGWRXEJZ6ECSLG7VDJ:/var/lib/docker/overlay2/l/JYQIR5JVEUVQPHEF452BRDVC23:/var/lib/docker/overlay2/l/AUDTRIBKXDZX62ANXO75LD3DW5:/var/lib/docker/overlay2/l/RFFN2MQPDHS2Z'
Unexpected end of /proc/mounts line `KNEJCAQH6YG5S:/var/lib/docker/overlay2/l/7LZSAIYKPQ56QB6GEIB2KZTDQA:/var/lib/docker/overlay2/l/CP2WSFS5347GXQZMXFTPWU4F3J:/var/lib/docker/overlay2/l/SJHIWRVQO5IENQFYDG6R5VF7EB:/var/lib/docker/overlay2/l/ICNNZZ4KB64VEFSKEQZUF7XI63:/var/lib/docker/overlay2/l/SOHRMEBEIIP4MRKRRUWMFTXMU2:/var/lib/docker/overlay2/l/DL4GM7DYQUV4RQE4Z6H5XWU2AB:/var/lib/docker/overlay2/l/JNEAR5ISUKIBKQKKZ6GEH6T6NP:/var/lib/docker/overlay2/l/LIAK7F7Q4SSOJBKBFY4R66J2C3:/var/lib/docker/overlay2/l/MYL6XNGBKKZO5CR3PG3HIB475X:/var/lib/do'
That message is printed for code line
MPI_Init(&argc,&argv);
To make the problem more complex to understand, a warning message is printed only when the host machine is mac os x, for linux host all is ok.
Except for warning message all works fine. I do not know how OpenMPI and docker well enough how this can be fixed.
This is likely due to your /proc/mount file having a line in it greater than 512 characters, causing the hwloc module of OpenMPI to fail to parse it correctly. Docker has a tendency to put very long lines into /proc/mounts. You can see the bug in openmpi-1.10.7/opal/mca/hwloc/hwloc191/hwloc/src/topology-linux.c:1677:
static void
hwloc_find_linux_cpuset_mntpnt(char **cgroup_mntpnt, char **cpuset_mntpnt, int fsroot_fd)
{
#define PROC_MOUNT_LINE_LEN 512
char line[PROC_MOUNT_LINE_LEN];
FILE *fd;
*cgroup_mntpnt = NULL;
*cpuset_mntpnt = NULL;
/* ideally we should use setmntent, getmntent, hasmntopt and endmntent,
* but they do not support fsroot_fd.
*/
fd = hwloc_fopen("/proc/mounts", "r", fsroot_fd);
if (!fd)
return;
This can be fixed by increasing the value of PROC_MOUNT_LINE_LEN, although that should be considered a temporary workaround.
This issue should be fixed in hwloc since 1.11.3 (released 2 years ago). You can either upgrade to OpenMPI 3.0 which contains a hwloc 1.11.7 >= 1.11.3. Or recompile OpenMPI to use an external hwloc instead of the old embedded one.
I am using MT7688 module with openWRT OS, version 15.05. I did install usbip into the device with:
#opkg install http://downloads.lede-project.org/releases/17.01.1/targets/ramips/mt7688/packages/kmod-usbip-client_4.4.61-1_mipsel_24kc.ipk
#opkg install http://downloads.lede-project.org/releases/17.01.1/targets/ramips/mt7688/packages/kmod-usbip-server_4.4.61-1_mipsel_24kc.ipk
#opkg install http://downloads.lede-project.org/releases/17.01.1/targets/ramips/mt7688/packages/kmod-usbip_4.4.61-1_mipsel_24kc.ipk
Failure scenario:
root#mylinkit:/# usbip
-ash: usbip: not found
So, looks like something broken at user space. Do any one know the solution for it?
Below are the logs which shows kernel module is installed:
root#mylinkit:/# lsmod|grep usbip
usbip_core 4768 2 vhci_hcd
usbip_host 11256 0
root#mylinkit:/# find -name *usbip*
./etc/modules.d/usbip-server
./etc/modules.d/usbip
./etc/modules.d/usbip-client
./lib/modules/3.18.23/usbip-core.ko
./lib/modules/3.18.23/usbip-host.ko
./overlay/upper/etc/modules.d/usbip-server
./overlay/upper/etc/modules.d/usbip
./overlay/upper/etc/modules.d/usbip-client
./overlay/upper/lib/modules/3.18.23/usbip-core.ko
./overlay/upper/lib/modules/3.18.23/usbip-host.ko
./overlay/upper/usr/lib/opkg/info/kmod-usbip-server.postinst-pkg
./overlay/upper/usr/lib/opkg/info/kmod-usbip.control
./overlay/upper/usr/lib/opkg/info/kmod-usbip-server.prerm
./overlay/upper/usr/lib/opkg/info/kmod-usbip-client.postinst
./overlay/upper/usr/lib/opkg/info/kmod-usbip.list
./overlay/upper/usr/lib/opkg/info/kmod-usbip-client.prerm
./overlay/upper/usr/lib/opkg/info/kmod-usbip-server.list
./overlay/upper/usr/lib/opkg/info/kmod-usbip-server.postinst
./overlay/upper/usr/lib/opkg/info/kmod-usbip-client.control
./overlay/upper/usr/lib/opkg/info/kmod-usbip.postinst
./overlay/upper/usr/lib/opkg/info/kmod-usbip.prerm
./overlay/upper/usr/lib/opkg/info/kmod-usbip-server.control
./overlay/upper/usr/lib/opkg/info/kmod-usbip.postinst-pkg
./overlay/upper/usr/lib/opkg/info/kmod-usbip-client.postinst-pkg
./overlay/upper/usr/lib/opkg/info/kmod-usbip-client.list
./sys/bus/usb/drivers/usbip-host
./sys/devices/platform/vhci_hcd/usbip_debug
./sys/module/usbip_core
./sys/module/usbip_core/parameters/usbip_debug_flag
./sys/module/usbip_core/holders/usbip_host
./sys/module/usbcore/holders/usbip_host
./sys/module/usbip_host
./sys/module/usbip_host/drivers/usb:usbip-host
./usr/lib/opkg/info/kmod-usbip-server.postinst-pkg
./usr/lib/opkg/info/kmod-usbip.control
./usr/lib/opkg/info/kmod-usbip-server.prerm
./usr/lib/opkg/info/kmod-usbip-client.postinst
./usr/lib/opkg/info/kmod-usbip.list
./usr/lib/opkg/info/kmod-usbip-client.prerm
./usr/lib/opkg/info/kmod-usbip-server.list
./usr/lib/opkg/info/kmod-usbip-server.postinst
./usr/lib/opkg/info/kmod-usbip-client.control
./usr/lib/opkg/info/kmod-usbip.postinst
./usr/lib/opkg/info/kmod-usbip.prerm
./usr/lib/opkg/info/kmod-usbip-server.control
./usr/lib/opkg/info/kmod-usbip.postinst-pkg
./usr/lib/opkg/info/kmod-usbip-client.postinst-pkg
./usr/lib/opkg/info/kmod-usbip-client.list
I spend much time to figure out the solution. And in the end, doubt was correct. The installer ipk from release branch, as mentioned in query post, does not have user space binaries.
Solution: To get rid of it, I took complete source from official openwrt
- `git clone https://github.com/openwrt/openwrt`
- `make menuconfig`
- *Enabling from menuconfig*
- `networking->usbip` `networking->usbip-client` and `networking->usbip-server`
And after compiling I got two binaries in sbin
/usr/sbin/usbip
/usr/sbin/usbipd
Which was needed and I was looking for. It works perfectly now.
I am trying to find a way to reserve physical memory for a proprietary memory type hardware as early as possible after system boots up (Linux CentOs with Intel Xeon server platform).
I did the following at setup_arch() in arch/x86/kernel/setup.c and it works, but found out that I am not allowed to patch the kernel. The requirement is no BIOS and kernel mod.
setup_arch()
{
....
// Calls a proprietary function that returns custom proprietary memory module's starting address and size.
memblock_reserve(mem_start_addr, mem_size);
.....
}
I cannot use memmap=xx/xx either at Grub, because the start and size of the device is unknown (it has to be "discovered" by software)
Is there any way to do this?
One idea is to write a custom grub module and set memmap=xx using it.
The following is how to do it.
Note that following method only works above CentOS 7 since CentOS 6.x or below uses grub 0.9x .
In that case, you may have to modify code of grub 0.9x and replace /boot/grub/stage1 or /boot/grub/stage2
$ git clone git://git.savannah.gnu.org/grub.git
$ cd grub
$ git checkout grub-2.02-beta2 # CentOS 7 currently uses grub-2.02-beta
$ vim grub-core/Makefile.core.def # add following row
module = {
name = my_custom_module;
common = lib/my_custom_module.c;
};
$ vim grub-core/lib/my_custom_module.c # create following file
#include <grub/dl.h>
#include <grub/env.h>
GRUB_MOD_LICENSE ("GPLv3+");
GRUB_MOD_INIT(my_custom_module){
// Calls a proprietary function that returns custom proprietary memory module's starting address and size.
const char *mem_size = "123";
grub_env_set("my_memsize",mem_size);
}
GRUB_MOD_FINI(my_custom_module){
}
$ ./autogen.sh
$ ./configure
$ make
Now you can find that grub-core/my_custom_module.mod is created.
so copy it to /boot/grub2/i386-pc/ (or whatever your *.mod file exists)
Edit the grub.conf and add something like
insmod my_custom_module
linux /boot/vmlinuz-3.10.el7.x86_64 root=UUID=1a3b5c7d9 ro memmap=${my_memsize}
I am trying to run Cassandra. But, I am getting this error:
[root#SudeepMangu bin]# ./cassandra -f
xss = -ea -javaagent:/home/sudeep/apache-cassandra-1.2.5-src/lib/jamm-0.2.5.jar-
XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 -Xms930M -Xmx930M -Xmn200M -
XX:+HeapDumpOnOutOfMemoryError -Xss160k
Error occurred during initialization of VM Could not reserve enough space for object heap
I have tried setting JAVA_OPTS to max size with no effect.
See my answer here, https://stackoverflow.com/a/14447535/92463 which describes increasing the stack segment size. Edit the conf/cassandra-env.sh configuration script, at around line 185, and change the -Xss180k to a higher value.
if [ "`uname`" = "Linux" ] ; then
# reduce the per-thread stack size to minimize the impact of Thrift
# thread-per-client. (Best practice is for client connections to
# be pooled anyway.) Only do so on Linux where it is known to be
# supported.
# u34 and greater need 180k
JVM_OPTS="$JVM_OPTS -Xss180k"
fi
echo "xss = $JVM_OPTS"
I suggest testing values starting from -Xss200k and increasing in 20k increments. I have found that using -Xss280k on Ubuntu servers worked successfully.
Probably it's because of the 32bits java version. I changed my JAVA_HOME variable to the 64bits version by following this steps:
1) Hited both "Windows + R" keys and entered: sysdm.cpl
2) On the "System Properties" I pressed the 'Environment variables' button
3) In the textarea "Environment variables" I picked JAVA_HOME and clicked 'Edit'
4.a) In the "Variable Value" I took out the path
(it looks like this: C:\Program Files (x86)\Java\jdk1.8.0_192)
4.b) I Entered the 64bits path instead
it looks like this now: C:\Program Files\Java\jdk1.8.0_73
And that was it. Then I justed watched the cassandra server scipts running through...
And the heap memory problem is gone!
There is not enough space for cassandra. You have to change a value inside cassandra-env.sh file
open the cassandra-env.sh file
sudo vi cassandra-env.sh
In the document you will see JVM_OPTS="$JVM_OPTS -Xss180k"
Increase the chunk size between 250 to 300
Set stack size of 256K in cassandra-env.sh.