I was downloading torch and after 99% completion of the download, I am getting this error.
I am using Ubuntu, on an 8gb ram system.
the memory allocation
ankita#ankita-HP-Laptop-15-bs0xx:~$ free -h
total used free shared buff/cache available
Mem: 7.7G 2.0G 1.6G 495M 4.1G 5.0G
Swap: 0B 0B 0B
I've also experienced this problem due to lack of RAM. You may try increasing the swap space. Try methods mentioned here.
The best solution is to install pytorch using conda, rather than pip. You won't encounter memory error then.
Related
After updating to Sierra, MariaDB would no long start on my system. As it did not contain critical data, I removed it and attempted to reinstall via homebrew, however the post-install fails and I am unable to run mysql_install_db manually either. Everything is up to date and I have tried multiple times.
I was able to start the service and even create a new database and user, but when trying to set the user password the database would crash saying that mysql.user was corrupt. Running optimize/analyze/repair didn't seem to do anything. Also not sure what was done differently to allow MariaDB to start that one time...
The common error seems to be mysqld got signal 4 which makes me think that there is an incompatibility between MariaDB and the gcc?
Any help greatly appreciated.
Install MariaDB
Fails to run the post-install step.
> brew install mariadb
==> Downloading https://homebrew.bintray.com/bottles/mariadb-10.1.18.sierra.bottle.tar.gz
Already downloaded: /Users/username/Library/Caches/Homebrew/mariadb-10.1.18.sierra.bottle.tar.gz
==> Pouring mariadb-10.1.18.sierra.bottle.tar.gz
==> Using the sandbox
==> /usr/local/Cellar/mariadb/10.1.18/bin/mysql_install_db --verbose --user=username --basedir=/usr/local/Cellar/mariadb/10.1.18 --datadir=/usr/local/var/mysql --tmpdir=/
Last 15 lines from /Users/username/Library/Logs/Homebrew/mariadb/post_install.01.mysql_install_db:
shell> /usr/local/Cellar/mariadb/10.1.18/bin/mysql -u root mysql
mysql> show tables;
Try 'mysqld --help' if you have problems with paths. Using
--general-log gives you a log in /usr/local/var/mysql that may be helpful.
The latest information about mysql_install_db is available at
https://mariadb.com/kb/en/installing-system-tables-mysql_install_db
MariaDB is hosted on launchpad; You can find the latest source and
email lists at http://launchpad.net/maria
Please check all of the above before submitting a bug report
at http://mariadb.org/jira
Warning: The post-install step did not complete successfully
You can try again using `brew postinstall mariadb`
==> Caveats
A "/etc/my.cnf" from another install may interfere with a Homebrew-built
server starting up correctly.
To connect:
mysql -uroot
To have launchd start mariadb now and restart at login:
brew services start mariadb
Or, if you don't want/need a background service you can just run:
mysql.server start
==> Summary
🍺 /usr/local/Cellar/mariadb/10.1.18: 574 files, 136.6M
Run Post Install via Homebrew
> brew postinstall mariadb
==> Using the sandbox
==> /usr/local/Cellar/mariadb/10.1.18/bin/mysql_install_db --verbose --user=username --basedir=/usr/local/Cellar/mariadb/10.1.18 --datadir=/usr/local/var/mysql --tmpdir=/
Last 15 lines from /Users/username/Library/Logs/Homebrew/mariadb/post_install.01.mysql_install_db:
shell> /usr/local/Cellar/mariadb/10.1.18/bin/mysql -u root mysql
mysql> show tables;
Try 'mysqld --help' if you have problems with paths. Using
--general-log gives you a log in /usr/local/var/mysql that may be helpful.
The latest information about mysql_install_db is available at
https://mariadb.com/kb/en/installing-system-tables-mysql_install_db
MariaDB is hosted on launchpad; You can find the latest source and
email lists at http://launchpad.net/maria
Please check all of the above before submitting a bug report
at http://mariadb.org/jira
READ THIS: https://git.io/brew-troubleshooting
Manually run mysql_install_db
> mysql_install_db --general-log
Installing MariaDB/MySQL system tables in '/usr/local/var/mysql' ...
2016-11-07 10:56:36 140735707972544 [Warning] 'THREAD_CONCURRENCY' is deprecated and will be removed in a future release.
2016-11-07 10:56:36 140735707972544 [Note] /usr/local/Cellar/mariadb/10.1.18/bin/mysqld (mysqld 10.1.18-MariaDB) starting as process 32902 ...
2016-11-07 10:56:36 7fff95e183c0 InnoDB: Warning: Using innodb_additional_mem_pool_size is DEPRECATED. This option may be removed in future releases, together with the option innodb_use_sys_malloc and with the InnoDB's internal memory allocator.
2016-11-07 10:56:36 140735707972544 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2016-11-07 10:56:36 140735707972544 [Note] InnoDB: The InnoDB memory heap is disabled
2016-11-07 10:56:36 140735707972544 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2016-11-07 10:56:36 140735707972544 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2016-11-07 10:56:36 140735707972544 [Note] InnoDB: Compressed tables use zlib 1.2.8
2016-11-07 10:56:36 140735707972544 [Note] InnoDB: Using SSE crc32 instructions
2016-11-07 10:56:36 140735707972544 [Note] InnoDB: Initializing buffer pool, size = 2.0G
2016-11-07 10:56:37 140735707972544 [Note] InnoDB: Completed initialization of buffer pool
161107 10:56:37 [ERROR] mysqld got signal 4 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
Server version: 10.1.18-MariaDB
key_buffer_size=33554432
read_buffer_size=2097152
max_used_connections=0
max_threads=102
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1079322 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x0 thread_stack 0x3c000
0 mysqld 0x00000001076e62dc my_print_stacktrace + 60
0 mysqld 0x00000001071c6b4e handle_fatal_signal + 632
0 libsystem_platform.dylib 0x00007fff8d307bba _sigtramp + 26
0 libcrypto.1.0.0.dylib 0x000000010886cebb OPENSSL_ia32cap_P + 8019
0 libcrypto.1.0.0.dylib 0x000000010878456d ssleay_rand_bytes + 248
0 mysqld 0x00000001076f5200 my_random_bytes + 32
0 mysqld 0x00000001075b2790 _Z27fil_space_create_crypt_data16fil_encryption_tj + 184
0 mysqld 0x000000010769cda6 _Z34innobase_start_or_create_for_mysqlv + 4566
0 mysqld 0x00000001075f28aa _ZL13innobase_initPv + 3046
0 mysqld 0x00000001071c76de _Z24ha_initialize_handlertonP13st_plugin_int + 94
0 mysqld 0x000000010732dd19 _ZL17plugin_initializeP11st_mem_rootP13st_plugin_intPiPPcb + 351
0 mysqld 0x000000010732d9c9 _Z11plugin_initPiPPci + 2767
0 mysqld 0x0000000107270c0a _ZL22init_server_componentsv + 1807
0 mysqld 0x000000010726f017 _Z11mysqld_mainiPPc + 10571
0 libdyld.dylib 0x00007fff8d0fa255 start + 1
0 ??? 0x000000000000000a 0x0 + 10
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
Installation of system tables failed! Examine the logs in
/usr/local/var/mysql for more information.
The problem could be conflicting information in an external
my.cnf files. You can ignore these by doing:
shell> /usr/local/Cellar/mariadb/10.1.18/scripts/scripts/mysql_install_db --defaults-file=~/.my.cnf
You can also try to start the mysqld daemon with:
shell> /usr/local/Cellar/mariadb/10.1.18/bin/mysqld --skip-grant --general-log &
and use the command line tool /usr/local/Cellar/mariadb/10.1.18/bin/mysql
to connect to the mysql database and look at the grant tables:
shell> /usr/local/Cellar/mariadb/10.1.18/bin/mysql -u root mysql
mysql> show tables;
Try 'mysqld --help' if you have problems with paths. Using
--general-log gives you a log in /usr/local/var/mysql that may be helpful.
The latest information about mysql_install_db is available at
https://mariadb.com/kb/en/installing-system-tables-mysql_install_db
MariaDB is hosted on launchpad; You can find the latest source and
email lists at http://launchpad.net/maria
Please check all of the above before submitting a bug report
at http://mariadb.org/jira
Starting DB
> mysql.server start
Starting MySQL
.161107 10:58:10 mysqld_safe Logging to '/usr/local/var/mysql/MacBook-Pro.local.err'.
ERROR!
> cat MacBook-Pro.local.err
161107 10:59:15 mysqld_safe Starting mysqld daemon with databases from /usr/local/var/mysql
2016-11-07 10:59:15 140735707972544 [Warning] 'THREAD_CONCURRENCY' is deprecated and will be removed in a future release.
2016-11-07 10:59:15 140735707972544 [Note] /usr/local/Cellar/mariadb/10.1.18/bin/mysqld (mysqld 10.1.18-MariaDB) starting as process 33473 ...
2016-11-07 10:59:15 140735707972544 [Warning] Setting lower_case_table_names=2 because file system for /usr/local/var/mysql/ is case insensitive
2016-11-07 10:59:15 140735707972544 [Note] Using unique option prefix 'myisam_recover' is error-prone and can break in the future. Please use the full name 'myisam-recover-options' instead.
2016-11-07 10:59:15 7fff95e183c0 InnoDB: Warning: Using innodb_additional_mem_pool_size is DEPRECATED. This option may be removed in future releases, together with the option innodb_use_sys_malloc and with the InnoDB's internal memory allocator.
2016-11-07 10:59:15 140735707972544 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2016-11-07 10:59:15 140735707972544 [Note] InnoDB: The InnoDB memory heap is disabled
2016-11-07 10:59:15 140735707972544 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2016-11-07 10:59:15 140735707972544 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2016-11-07 10:59:15 140735707972544 [Note] InnoDB: Compressed tables use zlib 1.2.8
2016-11-07 10:59:15 140735707972544 [Note] InnoDB: Using SSE crc32 instructions
2016-11-07 10:59:15 140735707972544 [Note] InnoDB: Initializing buffer pool, size = 2.0G
2016-11-07 10:59:15 140735707972544 [Note] InnoDB: Completed initialization of buffer pool
2016-11-07 10:59:15 140735707972544 [Note] InnoDB: The first specified data file ./ibdata1 did not exist: a new database to be created!
2016-11-07 10:59:15 140735707972544 [Note] InnoDB: Setting file ./ibdata1 size to 10 MB
2016-11-07 10:59:15 140735707972544 [Note] InnoDB: Database physically writes the file full: wait...
161107 10:59:15 [ERROR] mysqld got signal 4 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
Server version: 10.1.18-MariaDB
key_buffer_size=33554432
read_buffer_size=2097152
max_used_connections=0
max_threads=102
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1079322 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x0 thread_stack 0x3c000
0 mysqld 0x000000010b9952dc my_print_stacktrace + 60
0 mysqld 0x000000010b475b4e handle_fatal_signal + 632
0 libsystem_platform.dylib 0x00007fff8d307bba _sigtramp + 26
0 ??? 0x000000010eb4ae0b 0x0 + 4541689355
0 libcrypto.1.0.0.dylib 0x000000010ca2d56d ssleay_rand_bytes + 248
0 mysqld 0x000000010b9a4200 my_random_bytes + 32
0 mysqld 0x000000010b861790 _Z27fil_space_create_crypt_data16fil_encryption_tj + 184
0 mysqld 0x000000010b94bda6 _Z34innobase_start_or_create_for_mysqlv + 4566
0 mysqld 0x000000010b8a18aa _ZL13innobase_initPv + 3046
0 mysqld 0x000000010b4766de _Z24ha_initialize_handlertonP13st_plugin_int + 94
0 mysqld 0x000000010b5dcd19 _ZL17plugin_initializeP11st_mem_rootP13st_plugin_intPiPPcb + 351
0 mysqld 0x000000010b5dc9c9 _Z11plugin_initPiPPci + 2767
0 mysqld 0x000000010b51fc0a _ZL22init_server_componentsv + 1807
0 mysqld 0x000000010b51e017 _Z11mysqld_mainiPPc + 10571
0 libdyld.dylib 0x00007fff8d0fa255 start + 1
0 ??? 0x0000000000000009 0x0 + 9
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
161107 10:59:16 mysqld_safe mysqld from pid file /usr/local/var/mysql/MacBook-Pro.local.pid ended
System Information
OSX
10.12.1
Homebrew
> brew -v
Homebrew 1.0.9
Homebrew/homebrew-core (git revision 3a20; last commit 2016-11-06)
> brew update
Already up-to-date.
> brew doctor
Your system is ready to brew.
GCC
> gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin16.1.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
MariaDB Uninstall
brew remove mariadb
rm -rf /usr/local/var/mysql
brew cleanup
In the long tradition of working on a problem for days and then fixing it right after posting a question... I was able to install MariaDB using Homebrew on OSX Sierra.
I was about to remove and reinstall XCode and the command line tools but for some reason decided to make sure that it was pointed to the correct path and ran:
sudo xcode-select --switch /Applications/Xcode.app
At the same time I zeroed in on the ssleay_rand_bytes and my_random_bytes part of the stacktrace and thought maybe openssl wasn't installed (it was) but then reinstalled it using homebrew. Then I decided to try one more time before killing XCode, and it worked...
openssl already installed
> brew install openssl
Warning: openssl-1.0.2j already installed
reinstall openssl
> brew reinstall openssl
==> Reinstalling openssl with --universal
==> Using the sandbox
==> Downloading https://www.openssl.org/source/openssl-1.0.2j.tar.gz
######################################################################## 100.0%
==> make clean
==> perl ./Configure --prefix=/usr/local/Cellar/openssl/1.0.2j --openssldir=/usr/local/etc/openssl no-ssl2 zlib-dynamic shared enable-cms darwin64-x86_64-cc enable-ec_nistp_6
==> make depend
==> make
xcode-select==> make test
==> make clean
==> perl ./Configure --prefix=/usr/local/Cellar/openssl/1.0.2j --openssldir=/usr/local/etc/openssl no-ssl2 zlib-dynamic shared enable-cms darwin-i386-cc
==> make depend
==> make
==> make test
==> make install MANDIR=/usr/local/Cellar/openssl/1.0.2j/share/man MANSUFFIX=ssl
==> lipo -create build-x86_64/libcrypto.1.0.0.dylib build-i386/libcrypto.1.0.0.dylib -output /usr/local/Cellar/openssl/1.0.2j/lib/libcrypto.1.0.0.dylib
==> lipo -create build-x86_64/libcrypto.a build-i386/libcrypto.a -output /usr/local/Cellar/openssl/1.0.2j/lib/libcrypto.a
==> lipo -create build-x86_64/libssl.1.0.0.dylib build-i386/libssl.1.0.0.dylib -output /usr/local/Cellar/openssl/1.0.2j/lib/libssl.1.0.0.dylib
==> lipo -create build-x86_64/libssl.a build-i386/libssl.a -output /usr/local/Cellar/openssl/1.0.2j/lib/libssl.a
==> lipo -create build-x86_64/engines/lib4758cca.dylib build-i386/engines/lib4758cca.dylib -output /usr/local/Cellar/openssl/1.0.2j/lib/engines/lib4758cca.dylib
==> lipo -create build-x86_64/engines/libaep.dylib build-i386/engines/libaep.dylib -output /usr/local/Cellar/openssl/1.0.2j/lib/engines/libaep.dylib
==> lipo -create build-x86_64/engines/libatalla.dylib build-i386/engines/libatalla.dylib -output /usr/local/Cellar/openssl/1.0.2j/lib/engines/libatalla.dylib
==> lipo -create build-x86_64/engines/libcapi.dylib build-i386/engines/libcapi.dylib -output /usr/local/Cellar/openssl/1.0.2j/lib/engines/libcapi.dylib
==> lipo -create build-x86_64/engines/libchil.dylib build-i386/engines/libchil.dylib -output /usr/local/Cellar/openssl/1.0.2j/lib/engines/libchil.dylib
==> lipo -create build-x86_64/engines/libcswift.dylib build-i386/engines/libcswift.dylib -output /usr/local/Cellar/openssl/1.0.2j/lib/engines/libcswift.dylib
==> lipo -create build-x86_64/engines/libgmp.dylib build-i386/engines/libgmp.dylib -output /usr/local/Cellar/openssl/1.0.2j/lib/engines/libgmp.dylib
==> lipo -create build-x86_64/engines/libgost.dylib build-i386/engines/libgost.dylib -output /usr/local/Cellar/openssl/1.0.2j/lib/engines/libgost.dylib
==> lipo -create build-x86_64/engines/libnuron.dylib build-i386/engines/libnuron.dylib -output /usr/local/Cellar/openssl/1.0.2j/lib/engines/libnuron.dylib
==> lipo -create build-x86_64/engines/libpadlock.dylib build-i386/engines/libpadlock.dylib -output /usr/local/Cellar/openssl/1.0.2j/lib/engines/libpadlock.dylib
==> lipo -create build-x86_64/engines/libsureware.dylib build-i386/engines/libsureware.dylib -output /usr/local/Cellar/openssl/1.0.2j/lib/engines/libsureware.dylib
==> lipo -create build-x86_64/engines/libubsec.dylib build-i386/engines/libubsec.dylib -output /usr/local/Cellar/openssl/1.0.2j/lib/engines/libubsec.dylib
==> lipo -create build-x86_64/openssl build-i386/openssl -output /usr/local/Cellar/openssl/1.0.2j/bin/openssl
==> Caveats
A CA file has been bootstrapped using certificates from the SystemRoots
keychain. To add additional certificates (e.g. the certificates added in
the System keychain), place .pem files in
/usr/local/etc/openssl/certs
and run
/usr/local/opt/openssl/bin/c_rehash
This formula is keg-only, which means it was not symlinked into /usr/local.
Apple has deprecated use of OpenSSL in favor of its own TLS and crypto libraries
Generally there are no consequences of this for you. If you build your
own software and it requires this formula, you'll need to add to your
build variables:
LDFLAGS: -L/usr/local/opt/openssl/lib
CPPFLAGS: -I/usr/local/opt/openssl/include
PKG_CONFIG_PATH: /usr/local/opt/openssl/lib/pkgconfig
==> Summary
🍺 /usr/local/Cellar/openssl/1.0.2j: 1,696 files, 17.3M, built in 11 minutes 1 second
install mariadb
> brew install mariadb
==> Downloading https://homebrew.bintray.com/bottles/mariadb-10.1.18.sierra.bottle.tar.gz
Already downloaded: /Users/username/Library/Caches/Homebrew/mariadb-10.1.18.sierra.bottle.tar.gz
==> Pouring mariadb-10.1.18.sierra.bottle.tar.gz
==> Using the sandbox
==> /usr/local/Cellar/mariadb/10.1.18/bin/mysql_install_db --verbose --user=username --basedir=/usr/local/Cellar/mariadb/10.1.18 --datadir=/usr/local/var/mysql --tmpdir=/
==> Caveats
A "/etc/my.cnf" from another install may interfere with a Homebrew-built
server starting up correctly.
To connect:
mysql -uroot
To have launchd start mariadb now and restart at login:
brew services start mariadb
Or, if you don't want/need a background service you can just run:
mysql.server start
==> Summary
🍺 /usr/local/Cellar/mariadb/10.1.18: 574 files, 136.6M
connect to mariadb
> mysql
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 3
Server version: 10.1.18-MariaDB Homebrew
Copyright (c) 2000, 2016, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> exit
Bye
Whenever I try to install a gem with gem install [gem-name], I keep getting this error:
ERROR: While executing gem ... (Errno::ENOLCK)
No locks available # rb_file_flock - /home/abod/.gem/specs/api.rubygems.org%443/quick/Marshal.4.8/bundler-1.7.12.gemspec
I did gem install bundler just for illustration, but the Errno::ENOLCK will occur regardless of the gem I'm trying to install. I've searched around and can't seem to find anything about this error.
Here is the out put from gem env, in case that helps.
RubyGems Environment:
- RUBYGEMS VERSION: 2.4.5
- RUBY VERSION: 2.2.0 (2014-12-25 patchlevel 0) [x86_64-linux]
- INSTALLATION DIRECTORY: /home/abod/.rvm/gems/ruby-2.2.0#global
- RUBY EXECUTABLE: /home/abod/.rvm/rubies/ruby-2.2.0/bin/ruby
- EXECUTABLE DIRECTORY: /home/abod/.rvm/gems/ruby-2.2.0#global/bin
- SPEC CACHE DIRECTORY: /home/abod/.gem/specs
- SYSTEM CONFIGURATION DIRECTORY: /home/abod/.rvm/rubies/ruby-2.2.0/etc
- RUBYGEMS PLATFORMS:
- ruby
- x86_64-linux
- GEM PATHS:
- /home/abod/.rvm/gems/ruby-2.2.0#global
- GEM CONFIGURATION:
- :update_sources => true
- :verbose => true
- :backtrace => false
- :bulk_threshold => 1000
- REMOTE SOURCES:
- https://rubygems.org/
- SHELL PATH:
- /home/abod/.rvm/gems/ruby-2.2.0#global/bin
- /home/abod/.rvm/rubies/ruby-2.2.0/bin
- /usr/local/bin
- /usr/bin
- /usr/local/sbin
- /usr/sbin
- /home/abod/.rvm/bin
- /home/abod/.rvm/bin
At the suggestion of #joelparkerhenderson, here are the output of some commands that may be helpful.
$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 2063389
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 32768
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 2063389
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
$ uname -a
Linux biohen36 3.14.23-100.fc19.x86_64 #1 SMP Thu Oct 30 18:36:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
$ stat /home/abod/.gem/specs/api.rubygems.org%443/quick/Marshal.4.8/bundler-1.7.12.gemspec
File: ‘/home/abod/.gem/specs/api.rubygems.org%443/quick/Marshal.4.8/bundler-1.7.12.gemspec’
Size: 1025 Blocks: 8 IO Block: 1048576 regular file
Device: 2fh/47d Inode: 2285894 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 730/ abod) Gid: ( 1013/ wommack)
Access: 2015-02-03 01:12:35.573192019 -0500
Modify: 2015-02-02 13:53:41.227813208 -0500
Change: 2015-02-02 13:53:41.227813208 -0500
Birth: -
$ fuser -m /home/abod/.gem/specs/api.rubygems.org%443/quick/Marshal.4.8/bundler-1.7.12.gemspec
/home/abod/.gem/specs/api.rubygems.org%443/quick/Marshal.4.8/bundler-1.7.12.gemspec: 57788c
There were more processes accessing the file, but I killed them and tried to install again, but I still got the lock error. I'm not out of disk space either.
Here is some more info:
This is on a compute cluster. The home directory /home/abod is symlinked somewhere on /mnt which mounts to some other machine on the network.
The output from mount has been requested by a few commenters. Here are the lines regarding the home directory:
fileserver:/homes on /home type nfs (rw,noatime,nodiratime,vers=3,rsize=1048576,wsize=1048576,namlen=255,soft,nocto,noacl,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=128.175.xxx.xxx,mountvers=3,mountport=20048,mountproto=udp,local_lock=none,addr=128.175.xxx.xxx)
-hosts on /net/fileserver/homes type autofs (rw,relatime,fd=13,pgrp=1368,timeout=300,minproto=5,maxproto=5,offset)
fileserver:/homes on /net/fileserver/homes type nfs (rw,nosuid,nodev,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=128.175.xxx.xxx,mountvers=3,mountport=20048,mountproto=udp,local_lock=none,addr=128.175.xxx.xxx)
Edit
I found this ticket on the rubygems github page that is related to my issue: https://github.com/rubygems/rubygems/issues/1176
Note: I'm offering a bounty to help the OP, because we need more expert help.
Here are some general ideas to get you started...
Is it possible that you're out of system resources, such as disk space?
Or your system is limiting the resources you can use?
Or trying to write to a volume where you don't have permissions or a lock daemon?
If no one has a better answer for you, by the time you read this, can you try running these commands then post the output in your question?
$ df
$ ulimit -a
$ uname -a
$ stat /home/abod/.gem/specs/api.rubygems.org%443/quick/Marshal.4.8/bundler-1.7.12.gemspec
$ fuser -m /home/abod/.gem/specs/api.rubygems.org%443/quick/Marshal.4.8/bundler-1.7.12.gemspec
If you want to kill any process accessing that file, that may be holding locks:
$ fuser --kill /home/abod/.gem/specs/api.rubygems.org%443/quick/Marshal.4.8/bundler-1.7.12.gemspec
You can discover if the issue is with Ruby vs. gem by running this:
path = "/home/abod/.gem/specs/api.rubygems.org%443/quick/Marshal.4.8/bundler-1.7.12.gemspec"
f = File.open(path, File::RDWR|File::CREAT, 0644){|f|
f.flock(File::LOCK_EX)
f.flock(File::LOCK_UN)
}
If the above code fails, then the most likely explanation is that you're using a filesystem that doesn't support file locking. This would be consistent with your home directory being mounted to some other filesystem, such as using NFS without a lock daemon.
Edit: OP writes:
Running the code you suggest: test.rb:4:in flock': No locks available # rb_file_flock - /home/abod/.gem/specs/api.rubygems.org%443/quick/Marshal.4.8/bundler-1.7.12.gemspec (Errno::ENOLCK) from test.rb:4:inblock in ' from test.rb:3:in open' from test.rb:3:in'
That looks to me like your filesystem doesn't provide locking.
I have two suggestions and I'm also adding a bounty to your question to help attract expert attention.
If you have any filesystem space on that computer that isn't a mounted compute cluster, try installing a gem there. You can set the GEM_HOME environment variable like this:
GEM_HOME=/foo/bar gem install <name>
If you can use a similar system, such as the same OS on VirtualBox or VMWare, then you can use the bundler gem, a Gemfile, and the command bundle pack. This creates a directory full of the gems listed in the Gemfile. You can then copy this directory anywhere you want, for example by using rsync, or scp, or sftp, etc. (This doesn't help much though with native gems, such as pg for PostgreSQL - you would need to be sure to install all the PostgresSQL dependencies and headers on your own).
Ask your Sys Admin to unmount and mount the partition; the NFS Lock Daemon messes up at times and this will reset it.
(Not exactly an elegant or long-term solution, I know).
I'm using laravel + composer . I'm loading way/generators package and when I run composer update give me this error:
Loading composer repositories with package information Updating
dependencies (including require-dev)
Fatal error: Allowed memory size of 536870912 bytes exhausted (tried
to allocate 67108864 bytes) in
phar:///usr/local/Cellar/composer/1.0.0-alpha8/libexec/composer.phar/src/Composer/DependencyResolver/Solver.php
on line 170
I think, This is because composer update has used all the memory.
php -d memory_limit=1G /usr/local/Cellar/composer/1.0.0-alpha8/libexec/composer.phar update
This works for me on a mac.
Also check out to use composer install.
If you are on a server with less amount of RAM like 512MB you will need to create swap memory. Here is how you do it on ubuntu
touch swap.img
chmod 600 swap.img
Using 1GB for swap
dd if=/dev/zero of=/var/swap.img bs=1024k count=1000
mkswap /var/swap.img
swapon /var/swap.img
Here is the full article https://www.digitalocean.com/community/tutorials/how-to-configure-virtual-memory-swap-file-on-a-vps
I was having problem to install laravel with composer.
Original command was:
composer global require "laravel/installer=~1.1"
And Error message was:
Loading composer repositories with package information Updating dependencies (including require-dev)
Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 67108864 bytes) in phar:///usr/local/Cellar/composer/1.0.0-alpha8/libexec/composer.phar/src/Composer/DependencyResolver/Solver.php on line 170
Following command should work:
php -dmemory_limit=1G /usr/local/Cellar/composer/1.0.0-alpha8/libexec/composer.phar global require "laravel/installer=~1.1"
In my case I encountered the same problem and manage to solve by halting the Apache and MySQL service and then proceeding to install the laravel application via composer.
The sudo service stop apache2 followed by sudo service stop mysql stop this in turn killed the application that were consuming memory I then proceeded to install the Laravel via the normal composer command once done I just restarted the service and everything was fine.
I found solution, after read this post: https://github.com/composer/composer/issues/1898
Thank you to "Dynom, commented on Jul 4, 2013"
Needing 512MiB RAM for a package-manager is already a bit much, but I
also exceed it. The interesting part is that I exceed 512 MiB RAM (up
to around 800 MiB RAM according to my process output) when I use my
private Satis repository (which is actually just a cache for all
Github public repositories). I do not exceed it otherwise. Just by
adding my satis repository, composer consumes almost 400 MiB more RAM
To all the others raising their PHP CLI memory_limit globally, I
recommend against that. Instead I suggest to put it in the command
line, like so:
php -dmemory_limit=1G {composer location} update
Example:
php -dmemory_limit=1G bin/composer.phar update
Otherwise you could potentially miss certain unintended memory related
behaviour in your own work.
Tested on: Debian version 6
Do you have the last version of composer? I've fixed that problem with a simple update:
sudo composer self-update
I run go build in the $GOPATH of my arch Vagrant box.
But it prints out
runtime: panic before malloc heap initialized
fatal error: runtime: cannot allocate heap metadata
And the box is 3.10.9-1-ARCH x86_64, memory 242M.
Why I can't build go files in the box?
Thanks in advance.
Looks like this is caused by not enough virtual memory
$ ulimit -v 242000
$ go build prog.go
runtime: panic before malloc heap initialized
fatal error: runtime: cannot allocate heap metadata
64bit go needs lots of virtual memory space but not necessarily that much real memory.
You could fix this by allocating more memory to the container.
You could also play with the setting of /proc/sys/vm/overcommit_memory.
You could also try allocating swap to the container (if possible).
I have problems with Ocropus 4.4. (open source OCR). I installed Ocropus and neccessary libries following this script. Compilation/Installation goes without any problem.
However after successful installation of ocropus, I am not able to run any of ocropus-* commands. Ocropus-page and ocropus-hocr crash without giving any error meaningful message. I just get a cryptic killed after 2 minutes of processing.
ocropus-pages page_001.jpeg
[note] line recognizer: >
[note] *** 1 page_001.jpeg ***
Killed
I do not know where to start to fix it. Has anybody an idea where to start?
My machine is XUbuntu 10.4 64bits (run in VirtualBox) with 512MB of base memory.
I would try to convert your images to uncrompressed tiff before processing. I know that ocropus is working closely with tesseract and that tesseract handles 1bpp uncompressed tiffs the best.
Despite this being an old question I thought I'd post a solution / some debug tips as I experienced the same problem under the same scenario. The scenario being: Debian running under VirtualBox with 512MB RAM
In order to debug "Killed" messages you should look into /var/log for help. In my case kern.log contained:
debian kernel: [89675.791910] Out of memory: Kill process 13004
(ocropus-rtrain) score 806 or sacrifice child
debian kernel: [89675.791951] Killed process 13004 (ocropus-rtrain)
total-vm:800816kB, anon-rss:412424kB, file-rss:4kB
It's likely you need to increase the amount of resources assigned to the VM particularly if you're running some big fancy window manager in the background!