I had a problem this morning deploying an application with capistrano.
# git push
# cap deploy:setup
Something strange happened and than I wasn't able to ssh to my host anymore.
Technical staff says (in Italian): "the commands you have run overwrote the shell binaries causing the system to be no more usable". Two options: I am a stupid, or they are wrong.
Here's the shell output on cap:deploy and then the error on ssh. Once the system (VPS) has been rebooted, I wasn't able to ssh anymore.
Any ideas?
mattia#desktop:/var/www/rails/my_application$ git push
Counting objects: 239, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (191/191), done.
Writing objects: 100% (202/202), 379.77 KiB, done.
Total 202 (delta 44), reused 0 (delta 0)
To ssh://mattia#my_application.it/~/git/my_application.git
96c1f19..3cc9e1c master -> master
mattia#desktop:/var/www/rails/my_application$ cap deploy:setup
* executing `deploy:setup'
* executing "mkdir -p /var/www/rails/my_application /var/www/rails/my_application/releases /var/www/rails/my_application/shared /var/www/rails/my_application/shared/system /var/www/rails/my_application/shared/log /var/www/rails/my_application/shared/pids && chmod g+w /var/www/rails/my_application /var/www/rails/my_application/releases /var/www/rails/my_application/shared /var/www/rails/my_application/shared/system /var/www/rails/my_application/shared/log /var/www/rails/my_application/shared/pids"
servers: ["beta.my_application.it"]
[beta.my_application.it] executing command
** [out :: beta.my_application.it]
** [out :: beta.my_application.it] malloc: ../bash/parse.y:2823: assertion botched
** [out :: beta.my_application.it] nunits < 30
** [out :: beta.my_application.it] Aborting...
command finished
failed: "env PATH=/usr/local/bin:/usr/bin:/bin GEM_PATH=/var/lib/gems/1.9.1 sh -c 'mkdir -p /var/www/rails/my_application /var/www/rails/my_application/releases /var/www/rails/my_application/shared /var/www/rails/my_application/shared/system /var/www/rails/my_application/shared/log /var/www/rails/my_application/shared/pids && chmod g+w /var/www/rails/my_application /var/www/rails/my_application/releases /var/www/rails/my_application/shared /var/www/rails/my_application/shared/system /var/www/rails/my_application/shared/log /var/www/rails/my_application/shared/pids'" on beta.my_application.it
mattia#desktop:/var/www/rails/my_application$ ssh beta.my_application.it
Linux my_application 2.6.18-194.26.1.el5.028stab079.2ent #1 SMP Fri Dec 17 19:44:51 MSK 2010 i686
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Feb 7 12:00:53 2011 from dynamic-adsl-xx-xx-xx-xx.------.------.it
malloc: ../bash/subst.c:4494: assertion botched
realloc: called with unallocated block argument
Aborting...Connection to beta.my_application.it closed.
The short-answer is no, unless you have other plugins that aren't standard, or someone gave you a messed up Gem. (Almost nobody bothers to validate the gem signatures.) The standard deploy:setup only creates a couple of symlinks, and directories.
It does run as root, and in theory if you were to set your variables to values (untested) such as set :deploy_to, '/bin/bash', it may damage the binary, but unless you did that, I'd say that's a non-issue.
You can debug this, without relying on a shell - by using SSH in command mode:
# ssh myuser#myserver -c 'history'
Which will dump out the history file (bash) of that user, so you can test if there's been any tampering on the server, you can also check it as root, and/or run commands such as who, last and other one-liners which give you back logs (you can also cat /var/log/messages and look for suspicious activity.
I'd say that the chance of Capistrano being responsible for this is 0 (Source: I'm the maintainer.) - but you can probably get your system back into a working state using the SHS command mode, as I mentioned above (ssh myuser#myserver -c 'aptitude install bash --force' for example)
A word to the wise, if you never figure out how this happened, erase the server and change your passwords… just use this as a method to get things back up and running. It's not a very subtle tactic, but if you've been hacked, a hacker could easily throw you out by making a user which uses an alternative shell, and corrupting yours.
It would also be a huge help from your admins, if they could give you /bin/bash - the contents of the file, so you can see if it's text, junk, corrupted binary, or something from your deploy.
Related
I am using vsql.exe on an external Vertica database for which I don't have any administrative access. I use some views with simple SELECT+FROM+WHERE queries.
These queries 90% of the time work just fine, but some times, randomly, I get this error:
ERROR 3326: Execution time exceeded run time cap of 00:00:45
The strange thing is that this error can happen way after those 45 seconds, even after 3 minutes. I've been told this is related to having different resource pools, but anyway I don't want to dig into that.
The problem is that when this occurs, vsql.exe returns errorlevel 0 and there is (apparently almost) no way to know this failed.
The output of the query is stored in a csv file. When it succeeds, it ends with (#### rows). But when it fails with this error, it just stops at any point of the csv, and its resulting size is around half of what's expected. This is of course not what you would expect when an error occurs, like no output or an empty one.
If there is a connection error or if the query has syntax errors, the errorlevel is not 0, so in those cases it behaves as expected.
I've tried many things, like increasing the timeout or adding -v ON_ERROR_STOP=ON to the vsql.exe parameters, but none of that helped.
I've googled a lot and found many people having this error, but the solutions are mostly related to increasing the timeouts, not related to the errorlevel returned.
Any help will be greatly appreciated.
TL;DR: how can I detect an error 3326 in a batch file like this?
#echo off
vsql.exe -h <hostname> -U <user> -w <pwd> -o output.cs -Ac "SELECT ....;"
echo %errorlevel% is always 0
if errorlevel 1 echo Error!! But this is never displayed.
Now that's really unexpected to me. I don't have Windows available just now, but trying on my Mac - at first just triggering a deliberate error:
$ vsql -h zbook -d sbx -U dbadmin -w $VSQL_PASSWORD -v ON_ERROR_STOP=ON -Ac "select * from foobarfoo"
ERROR 4566: Relation "foobarfoo" does not exist
$ echo $?
1
With ON_ERROR_STOP set to ON, this should be the behaviour everywhere.
Could you try what I did above through Windows, just with echo %ERRORLEVEL% instead of echo $?, just from the Windows command prompt and not in a batch file?
Next test: I run on resource pool general in my little test database, so I temporarily modify it to a runtime cap of 30 sec, run a silly query that will take over 30 seconds with ON_ERROR_STOP set to ON, collect the value returned by vsql and set the runtime cap of general back to NONE. I also have the %VSQL_* % env variables set so I don't have to repeat them all the time:
rem Windows way to set environment variables for vsql:
set VSQL_HOST=zbook
set VSQL_DATABASE=sbx
set VSQL_USER=dbadmin
set VSQL_PASSWORD=***masked***
Now for the test (backslashes, in Linux/MacOs escape a new line, which enables you to "word wrap" a shell command. Use the caret (^) in Windows for that):
marco ~/1/Vertica/supp $ # set a runtime cap
marco ~/1/Vertica/supp $ vsql -i -c \
"alter resource pool general runtimecap '00:00:30'"
ALTER RESOURCE POOL
Time: First fetch (0 rows): 116.326 ms. All rows formatted: 116.730 ms
marco ~/1/Vertica/supp $ vsql -v ON_ERROR_STOP=ON -iAc \
"select count(*) from one_million_rows a cross join one_million_rows b"
ERROR 3326: Execution time exceeded run time cap of 00:00:30
marco ~/1/Vertica/supp $ # test the return code
marco ~/1/Vertica/supp $ echo $?
1
marco ~/1/Vertica/supp $ # clear the runtime cap
marco ~/1/Vertica/supp $ vsql -i -c \
"alter resource pool general runtimecap NONE "
ALTER RESOURCE POOL
Time: First fetch (0 rows): 11.148 ms. All rows formatted: 11.383 ms
So it works in my case. Your line:
if errorlevel 1 echo Error!! But this is never displayed.
... never echoes anything because the previous line, with echo will return 0 to the shell, overriding the previous errorlevel.
Try it command by command on your Windows command prompt, and see what happens. Just echo %errorlevel%, without evaluating it.
And I notice that you are trying to export to CSV format. Then, try this:
Format the output unaligned (-A)
set the field separator to comma (-F ',')
remove the footer '(n rows)' (-P footer)
limit the output to 5 rows in the query for test
(I show the output before redirecting to file):
marco ~/1/Vertica/supp $ vsql -A -F ',' -P footer -c "select * from one_million_rows limit 5"
id,id_desc,dob,category,busid,revenue
0,0,1950-01-01,1,====== boss ========,0.000
1,-1,1950-01-02,2,kbv-000001kbv-000001,0.010
2,-2,1950-01-03,3,kbv-000002kbv-000002,0.020
3,-3,1950-01-04,4,kbv-000003kbv-000003,0.030
4,-4,1950-01-05,5,kbv-000004kbv-000004,0.040
Not aligning is much faster than aligning.
Then, as you spend most time in the fetching of the rows (that's because you get a timeout in the middle of an output file write process), try fetching more rows at a time than the default 1000. You will need to play with the value, depending on the network settings at your site until you get your best value:
-v ROWS_AT_A_TIME=10000
Once you're happy with the tested output, try this command (change the SELECT for your needs, of course ....):
marco ~/1/Vertica/supp $ vsql -A -F ',' -P footer \
-v ON_ERROR_STOP=ON -v ROWS_AT_A_TIME=10000 -o one_million_rows.csv \
-c "select * from one_million_rows"
marco ~/1/Vertica/supp $ wc -l one_million_rows.csv
1000001 one_million_rows.csv
The table actually contains one million rows. Note the line count in the file: 1,000,001. That's the title line included, but the footer (1000000 rows) removed.
When I run opensipsctl start command for start opensips that time I got one error.
ERROR: PID file /var/run/opensips.pid does not exist -- OpenSIPS start failed
So please help me to solve it.
open up opensipsctl, it includes the file opensipsctlrc, which defined $PID_FILE as /var/run/opensips.pid
Then in opensipsctl, when you run start one of the checks is..
if [ ! -s $PID_FILE ] ; then
echo
merr "PID file $PID_FILE does not exist -- OpenSIPS start failed"
exit 1
fi
Which is saying if then check of whethever '/var/run/opensips.pid exists and is bigger than 0 bytes' fails, then echo out the above error.
This means the file isn't being created.
If you look just above that line it does..
if [ $SYSLOG = 1 ] ; then
$OSIPSBIN -P $PID_FILE $STARTOPTIONS 1>/dev/null 2>/dev/null
else
$OSIPSBIN -P $PID_FILE -E $STARTOPTIONS
fi
Which is where opensips actually starts. I would suggest adding the following to your opensips.cfg if you havn't already..
# Logging
debug=6
log_stderror=no
log_facility=LOG_LOCAL0
..now everything will be logged to /var/log/syslog on boot.
Try boot again, then look at that log for info about what's happened.
Another thing to check, is the user you're running opensips as has permission to access the directory it's trying to create the pid file in.
I had the same error & it was driving me mad as well. I managed to trace it down to one of two things - I had both!
1/ A misconfiguration in the OpenSIPS config file. journalctl -xe should be able to tell you what the error is
2/ Something else is listening on the port that you are trying to listen on
For 2, you can try the below, if you have Ubuntu, to see if anything is already listening on that port
lsof -i :5060
I was able to see logs and fix issue by below steps
Set log_level=4 in opensips.cfg to view debug logs in /var/log/syslog
debug is deprecated in 2.4 and higher version.
You can refer here for different log level
While deploying a Rails app with Capistrano on Ubuntu 14.04, I am getting the following error:
fatal: destination path '/var/www/APP-NAME/repo' already exists and is not an empty directory.
cf5a389e] Running /usr/bin/env [ -f /var/www/rd/repo/HEAD ] on LINODE-INSTANCE-IP
DEBUG[cf5a389e] Command: [ -f /var/www/rd/repo/HEAD ]
DEBUG[cf5a389e] Finished in 0.005 seconds with exit status 1 (failed).
DEBUG[8899b95c] Running /usr/bin/env if test ! -d /var/www/rd; then echo "Directory does not exist '/var/www/rd'" 1>&2; false; fi on LINODE-INSTANCE-IP
DEBUG[8899b95c] Command: if test ! -d /var/www/rd; then echo "Directory does not exist '/var/www/rd'" 1>&2; false; fi
DEBUG[8899b95c] Finished in 0.005 seconds with exit status 0 (successful).
INFO[fc5f524b] Running /usr/bin/env git clone --mirror GIT_REPO_URL /var/www/APP-NAME/repo on LINODE-INSTANCE-IP
DEBUG[fc5f524b] Command: cd /var/www/APP-NAME && ( GIT_ASKPASS=/bin/echo GIT_SSH=/tmp/rd/git-ssh.sh /usr/bin/env git clone --mirror GIT-REPO-URL /var/www/APP-NAME/repo )
DEBUG[fc5f524b] fatal: destination path '/var/www/APP-NAME/repo' already exists and is not an empty directory.
Here are config files:
config/deploy/production.rb
config/deploy.rb
The only reason for this error I can find online is;
same host in more than one role, so that they're racing? For example I mean that you might have the same IP address defined as an :app role host more than once.
Which I guess isn't fitting with the above config files.
I had the same problem. The reason is in double definition of the role and/or server.
Try to remove
server 'SERVER-IP', user: 'USERNAME', roles: %w{app}
in production.rb and
role :app, "SERVER-IP"
in deploy.rb. The latter seems to be just simple syntax while the former - is extended one, so you in fact you declare roles twice (three time to be more precise: 2 in production.rb and 1 in deploy.rb). Hope it helps.
On a related note, I ran into this issue when changing my DB connections file setup on one of my deploys.
In this case, the old structure had one shared file for DB settings, while the newer had two. Even though these were declared in the recipe, I was getting errors when automated deletion of older builds were being done.
To resolve, I just deleted the older builds, and ran the cap [server name] deploy a few times to clear it out, and to verify this was no longer occurring. So far, it's been fine.
Problem:
I am trying to get sphinx running again after server reboot. There seems to be no sphinx.conf file when I try to start it running:
>searchd
Sphinx 2.0.4-release (r3135)
Copyright (c) 2001-2012, Andrew Aksyonoff
Copyright (c) 2008-2012, Sphinx Technologies Inc (http://sphinxsearch.com)
FATAL: no readable config file (looked in /etc/sphinxsearch/sphinx.conf, ./sphinx.conf).
I have run:
rake thinking_sphinx:configure
rake thinking_sphinx:index
rake thinking_sphinx:start
The problem is for some reason no etc/sphinxsearch/sphinx.conf file is being created... I am new to thinking_sphinx and this might not be the only problem (with the site), but it doesn't seem to be set up fully. For out put and more information read below:
Background info:
I am working on a project I didn't set up initially. We rebooted the server to see some of the changes we made in a constants file. But after the reboot the project no longer displays when you navigate to the site. When you put in the straight ip address it just says "Welcome to Nginx".
The port is open and working through our hosting server, so I was told I have to restart some services. One of the issues I came upon was with thinking_sphinx. This was the rake tasks for sphinx site I referenced. As well as common configuration issues for sphinx.
I set up the sphinx.yml development paths (we aren't using production). Then I ran
>rake thinking_sphinx:index
which seems to have worked even though it output some warnings:
Generating Configuration to /home/potato/streetpotato/config/development.sphinx.conf
(0.2ms) SELECT ##global.sql_mode, ##session.sql_mode;
Sphinx 2.0.4-release (r3135)
Copyright (c) 2001-2012, Andrew Aksyonoff
Copyright (c) 2008-2012, Sphinx Technologies Inc (http://sphinxsearch.com)
using config file '/home/potato/streetpotato/config/development.sphinx.conf'...
indexing index 'bar_core'...
WARNING: collect_hits: mem_limit=0 kb too low, increasing to 14080 kb
collected 249 docs, 0.0 MB
sorted 0.0 Mhits, 100.0% done
total 249 docs, 32394 bytes
total 0.254 sec, 127298 bytes/sec, 978.49 docs/sec
indexing index 'bar_delta'...
WARNING: collect_hits: mem_limit=0 kb too low, increasing to 14080 kb
collected 0 docs, 0.0 MB
total 0 docs, 0 bytes
total 0.003 sec, 0 bytes/sec, 0.00 docs/sec
skipping non-plain index 'bar'...
indexing index 'synonym_core'...
WARNING: collect_hits: mem_limit=0 kb too low, increasing to 13568 kb
collected 3 docs, 0.0 MB
sorted 0.0 Mhits, 100.0% done
total 3 docs, 103 bytes
total 0.003 sec, 30356 bytes/sec, 884.17 docs/sec
indexing index 'synonym_delta'...
WARNING: collect_hits: mem_limit=0 kb too low, increasing to 13568 kb
collected 0 docs, 0.0 MB
total 0 docs, 0 bytes
total 0.002 sec, 0 bytes/sec, 0.00 docs/sec
skipping non-plain index 'synonym'...
indexing index 'user_core'...
WARNING: collect_hits: mem_limit=0 kb too low, increasing to 13568 kb
collected 100 docs, 0.0 MB
sorted 0.0 Mhits, 100.0% done
total 100 docs, 3146 bytes
total 0.013 sec, 239348 bytes/sec, 7608.03 docs/sec
skipping non-plain index 'user'...
total 11 reads, 0.000 sec, 3.8 kb/call avg, 0.0 msec/call avg
total 37 writes, 0.000 sec, 2.5 kb/call avg, 0.0 msec/call avg
Then I ran
>rake thinking_sphinx:configure
Generating Configuration to /home/potato/streetpotato/config/development.sphinx.conf
(0.2ms) SELECT ##global.sql_mode, ##session.sql_mode;
Lastly running:
>rake thinking_sphinx:start
Started successfully (pid 29623).
Now even though my log says:
[Fri Nov 16 19:34:29.820 2012] [29623] accepting connections
There is still no sphinx.conf file being generated and when I try to use the searchd command it still gives me the error...
>searchd --stop
Sphinx 2.0.4-release (r3135)
Copyright (c) 2001-2012, Andrew Aksyonoff
Copyright (c) 2008-2012, Sphinx Technologies Inc (http://sphinxsearch.com)
FATAL: no readable config file (looked in /etc/sphinxsearch/sphinx.conf, ./sphinx.conf).
I am at a loss, I know this is super long but only because I am so lost and trying to give as much information as possible. I got further then I did yesterday with this but it still doesn't seem to be fully working. I might have to do more set up with unicorn or thin as well. I'm just trying to figure out how to get the site back up and running again... If any one has run into similar issues with their site going down after reboot and got it back up (specifically a rails project on Nginx and unicorn or thin using sphinx) any insight would be appreciated.
Thanks,
Alan
Calm down!! :-)
Firstly, you don't need a /etc/sphinxsearch/sphinx.conf file; that is just the default file that searchd tries to use when you don't specify any configuration file.
As your log output shows, your rails application is using /home/potato/streetpotato/config/development.sphinx.conf file when it starts the searchd process.
Run ps -fe | grep searchd on your dev machine; you should see something like this as the output:
501 14128 1 0 0:00.00 ttys004 0:00.00 searchd --pidfile --config /home/potato/streetpotato/config/development.sphinx.conf
501 14130 13546 0 0:00.00 ttys004 0:00.01 grep searchd
So rails app calls searchd with --config /home/potato/streetpotato/config/development.sphinx.conf argument, to specify a different conf file.
From your logs, it is clear that thinkingsphinx is running fine. You can confirm it further by logging into rails console and running a search method on one of the models which have thinking_sphinx indexes defined on them.
Eg: If your app has an Article model as shown in the above link, the following command will show all articles having National Parks in them:
$ rails console
> Article.search( "National Parks" )
=> [#<Article id: 15,... >, #<Article id: 22,...>,...]
The real problem is the application not showing after restarting the server. That has nothing to do with thinking sphinx which is running fine.
Try rolling back all the changes made in the constants file that you mention above, and make sure the application is working fine. Then start making the changes one by one and isolate the one change that breaks your application.
So yeah, this is a hole in ThinkingSphinx (IMHO) -- you can start the sphinxd server using the various rake tasks (which generate the config as needed) ... but this doesn't work in production.
On a project I worked in last year (running on a Linux server) we created an /etc/init.d script to start sphinxd -- it takes options including a path to the configuration file. We did our deploys with capistrano, and put generated code in app/shared -- a directory outside of the source tree. I believe there are some predefined capistrano tasks that will rebuild the Rails-specific config files when models change or otherwise affect what Sphinx does (same as the rake task you mention).
This was one of those cases for us where we had been putting off site search for a long time, and one of our developers got it "all set up" in an afternoon. Getting it deployed took a lot more work.
(Just saw answer from #prakash-murthy -- he provides some details of how to specify config path when you initialized sphinxd). But the trick is to have it start when the system starts and pointing to the config that ThinkingSphinx generates.)
Ok so after a day n a half I finally set it all up and got it running (it was more then just sphinx). I also had to get nginx and unicorn up and running in the background, since we didn't have scripts set up to restart them when the server was rebooted...
When rebooting the server you have to restart some services before the app will be accessible:
1) thinking_sphinx
reference sites
http://pat.github.com/ts/en/rake_tasks.html
http://www.claytonlz.com/2010/09/thinkingsphinx-conf-problems/
a)create/modify app/config/sphinx.yml
development:
morphology: stem_en
port: 9312
bin_path: "/usr/bin" # set up the path to binary for searchd
searchd_binary_name: searchd
indexer_binary_name: indexer
#mem_limit: 128M
test:
morphology: stem_en
port: 9312
mem_limit: 128M
production:
morphology: stem_en
port: 9312
mem_limit: 512M
# the searchd ip, in case it's not on localhost
# address: 10.10.0.0
# this is by default included in db/sphinx
# searchd_file_path: "/path/to/shared/folder/sphinx"
b)rake thinking_sphinx:index
c)rake thinking_sphinx:configure # creates config/development.sphinx.conf which helps define sphinx's indexing
d)# then you have to start sphinx, there are 2 ways to do this
rake thinking_sphinx:start
rake thinking_sphinx:stop
OR
searchd
searchd --stop
# only the rake commands worked for me, when I tried to run searchd
# I got an error FATAL: no readable config file (looked in /etc/sphinxsearch/sphinx.conf, ./sphinx.conf).
# for some reason we dont have a sphinx.conf file, but the rake commands work without it
e)# once you start thinking_sphinx check log/searchd.log file for the line
[Fri Nov 16 19:34:29.820 2012] [29623] accepting connections
2) nginx
reference site:
http://wiki.nginx.org/CommandLine
a) check that nginx is up and running
i) start server
# to check where nginx resides type in this into server console
which nginx
# whatever path it gives you is how you start the server this is my path
/usr/sbin/nginx
ii) stop server
/usr/sbin/nginx -s stop # use the path given by which command
3) unicorn (starting app server)
reference site:
http://codelevy.com/2010/02/09/getting-started-with-unicorn.html
a) test if unicorn will run after previous changes
unicorn_rails -p 3000
# the site should now be up and running, check that it is
# console should now log the different actions you do on the site
b) create unicorn.rb in config folder (if none is there)
# only start this step if the step above got the site running
# close the console or exit the process you started above
# contents of unicorn.rb
worker_processes 2 #(starts 2 child processes, not completely neccissary)
preload_app true
timeout 30
listen 3000
after_fork do |server, worker|
ActiveRecord::Base.establish_connection
end
c) run unicorn in the background
# make sure you exited the process above before running this
unicorn_rails -c config/unicorn.rb -D
# this was giving me an error that it said was logged by stderr
# I got the command to run by adding a command to the front
http://stackoverflow.com/questions/2325152/check-for-stdout-or-stderr
exec 2> /dev/null unicorn_rails -c config/unicorn.rb -D
d) (optional) check stats from starting unicorn
i) pgrep -lf unicorn_rails
#sample output
5374 unicorn_rails master -c config/unicorn.rb -D
5388 unicorn_rails worker[0] -c config/unicorn.rb -D # not needed currently
5391 unicorn_rails worker[1] -c config/unicorn.rb -D # not needed currently
ii) cat tmp/pids/unicorn.pid # from inside the streetpotato folder
#sample output
5374
When I run the script described here with my user, everything is well:
lorenzo#enzo:~/erlang/pei$ time erl -noshell -smp enabled -S 4 -s fib4 main 10000000
real 0m54.952s
user 1m16.090s
sys 0m0.070s
When I run it as root, it crashed:
lorenzo#enzo:~/erlang/pei$ sudo time erl -noshell -smp enabled -S 4 -s fib4 main 10000000
[sudo] password for lorenzo:
74.68user 0.04system 0:53.56elapsed 139%CPU (0avgtext+0avgdata 66064maxresident)k
0inputs+0outputs (0major+8306minor)pagefaults 0swaps
The error is reproduceable.
My questions are:
Can someone try to explain me what is happending there?
Is it a problem with the erlang runtime or with my OS?
Can someone reproduce this error?
I am running erlang 5.7.4 on ubuntu natty with kernel
Linux enzo 2.6.38-10-generic #46-Ubuntu SMP Tue Jun 28 15:07:17 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
on a Phenom X4.
Why do you think it crashed? time just shows more info when running as root. Page fault is not an error but just the way virtual memory works.
The difference between the two runs is that in the first run, you're running the shell builtin time, but in the second run, you're running whatever sudo finds in the path, which is /usr/bin/time. These two tools have different output formats.
$ type time
time is a shell keyword
$ time echo
real 0m0.000s
user 0m0.000s
sys 0m0.000s
$ type /usr/bin/time
/usr/bin/time is /usr/bin/time
$ /usr/bin/time echo
0.01user 0.00system 0:00.00elapsed 1000%CPU (0avgtext+0avgdata 2784maxresident)k
0inputs+0outputs (0major+217minor)pagefaults 0swaps