How do I get a core dump on OS X Lion? - postgresql

I am working on a PostgreSQL extension in C that segfaults, so I want to look at the core dump file on my OS X Lion box. However, there are no core files in /cores or anywhere else that I can find. It appears that they are enabled in the system but are limited to a size of 0:
> sysctl kern.coredump
kern.coredump: 1
> ulimit -c
0
I tried setting ulimit -c unlimited in the shell session I'm using to start and stop PostgreSQL, and it seems to stick:
> ulimit -c
unlimited
And yet no matter what I do, no core files. I am starting PostgreSQL with pg_ctl -c, where the -c tells PostgreSQL to generate core dumps. But the system has nothing. How can I get Lion to dump core files?

The /cores/ directory is not necessarily there in Lion , and if it's not there, you won't get cores. You should be able to set the ulimit (as you have), run a program like cat(1), quit with a SIGQUIT (control-backslash) and get a coredump:
lion:~ user$ ulimit -c unlimited
lion:~ user$ cat
^\
^\
Quit: 3 (core dumped)
lion:~ user$ ls -l /cores/
total 716584
-r-------- 1 user user 366891008 Jun 21 23:35 core.1263
lion:~ user$
Technical Note TN2124 http://developer.apple.com/library/mac/#technotes/tn2124/ as suggested by Yuji in https://stackoverflow.com/a/3783403/225077 is helpful.

Related

centos cannot coredump with ulimit -c is unlimited

I just installed CentOs 7 on my mac using Parallel Desktop.
Here is the result of ulimit -c:
[root#centos-linux test1]# ulimit -c
unlimited
Here is the content of /etc/security/limits.conf
soft core unlimited
But the is no coredump file created.
What else can I do to enable coredump?
This phenomenon results from false core dump file path.
I thought the coredump file should be created in current dir or /tmp. But it's not.
cat /proc/sys/kernel/core_pattern tells where the coredump files are.
In my system:
[root#centos-linux Linux]# cat /proc/sys/kernel/core_patternĀ 
/mydata/corefile/core-%e-%s-%u-%g-%p-%t
However, there is no /mydata/corefile in my system.
So I can created a new dir /mydata/corefile or using
sysctl -w kernel.core_pattern=/tmp/core-%e-%s-%u-%g-%p-%t
to get coredump file in /tmp.

CentOS Mondo Rescue Error to Restore the iso: Kernel Panic

I am trying to create an image (.iso) of my installed CentOS 5.11 system, for this i am using the "Mondo Rescue" with the command:
mondoarchive -Oi -9 -L -d /tmp/centos_iso -I / -T /tmp/centos_iso -p centos_image -s 4480m -E "/tmp|/var/spool/squid|/var/log"
The image is generated, and apparently is functional.
To install the iso in other machine i'm using the option "Nuke", in initialization page of "Mondo Rescue", like is represented in below image
When attempting to perform the installation, the following error occurs during the process:
Kernel panic - not syncing: No init found. Try passing init= options to kernel.

** WARNING: soft rlimits too low. Number of files is 256, should be at least 1000

i ran on Mac OSX capitan and everytime i run mongo shell, this warning will pop up. i tried:
sudo ulimit -n 1024
ulimit -n 1024
it still doesn't work. any ideas?
You should try to close your terminal and redo it. Or directly try it in your shell which runs mongodb.
Close the running MonogoDB
Run the following bash code:
sudo launchctl limit maxfiles 65536 65536
sudo launchctl limit maxproc 2048 2048
ulimit -n 65536
ulimit -u 2048
Close the terminal or bash and restart.
run ulimit -n in terminal to test if change successfully

vnstat not updating on certain interfaces

vnstat is updating only one interface every five minutes. I have to use
vnstat -u
to manually update the rest of interfaces. All interfaces are already enabled, but only one interface is updating every 5 minutes.
Check which user the vnstat daemon is running as using ps aux | grep [v]nstat.
I recently had the same problem and after priming the database with
vnstat -u -i eth0 as root the vnstat process couldn't write to the /var/lib/vnstat/eth0
file as it was running as user "vnstat".
If vnstat is running as user "vnstat" ensure that it has permission to write to /var/lib/vnstat/eth0.
When you add the interface for eth0 or ppp0 or whatever, make sure you do it as the vnstat user. ie
sudo -u vnstat vnstat -i ppp0 -u
If you run this as root first you are will have problems even if you chmod the file in /var/lib/vnstat. This is due to the creation of a back file called .ppp0 which you might miss if you are not looking for it. There will be an error in syslog saying that the backup file cannot be written.
So I was having a similar problem where i was getting the following:
$ vnstat -i eno1
eno1: not enough data available yet
I also tried every other command while pointing to eno1. I would sometimes even get:
Error: Unable to create database backup "/var/lib/vnstat/.eno1"
OR
Segmentation fault (core dumped)
I tried reinstalling, and everything else under the sun.
Following Andrew's answer to the 't' returned:
Error: Unable to open database "/var/lib/vnstat/eno1" for writing: Permission denied
so instead I did the following, but I'm not sure which one of these commands did the trick.
$ sudo vnstat -i eno1 -u
$ sudo vnstat -u -i eno1
Then I checked to see if the interface was working again:
$ sudo vnstat -i eno1
which returned:
>
Database updated: Wed Dec 5 10:17:37 2018
(eno1) since 1969-12-31
rx: 2 KiB tx: 1 KiB total: 3 KiB
monthly
rx | tx | total | avg. rate
------------------------+-------------+-------------+---------------
Dec '69 2 KiB | 1 KiB | 3 KiB | 0.00 kbit/s
------------------------+-------------+-------------+---------------
estimated -- | -- | -- |
daily
rx | tx | total | avg. rate
------------------------+-------------+-------------+---------------
today 2 KiB | 1 KiB | 3 KiB | 0.00 kbit/s
------------------------+-------------+-------------+---------------
estimated -- | -- | -- |
Now its finally able to read and write to eno1 log. I noticed this problem since conky was not showing up any stats reports on today && Month && total. I wasn't expecting anything under month, but after a couple days I was expecting something under hours.
I realise the rest will take a while to populate with data. But now I know for sure it is working. Also, my conky app is finally displaying the information.
However, prior to this solution, I had already chmod the file.
Additional info for newbies such as myself:
- make sure to check which interface you are using, I often see solutions for eth0 and others that do not appear when using "$ ifconfig". Enter:
$ ifconfig
and you should see on the left hand side of the results the interface name. Mine are, eno1, lo, and wlo1.
next to the label: "Link encap:" it should say if it is wireless, ethernet, or local loopback
lo is the local loopback a.k.a localhost/127.0.0.1
What I am not sure of, in my case, is the difference between eno1 and wlo1. they both say "Ethernet". I wonder if doesn't have something to do with my direct wifi printer.

Unable to run "gearman" command line tool with gearman 1.1.6

I am trying to run the example on "http://gearman.org/getting_started" on Ubuntu in VirtualBox environment.
At first I tried to download an old version 0.16 by using apt-get install gearman-job-server, apt-get install gearman-tools and everything worked well. The server ran in the background, I was able to create 2 workers and verify that I can call them by creating a client.
I decided to download and compile the latest version, 1.1.6. Now, I am trying to do the same thing with the new version and I am having errors.
I run the server as admin:
sudo gearmand
The statement
gearadmin --getpid
seems to work - it returns me the process ID of the server. Thus, the server is running, and this answer is not relevant.
Now, I am adding a worker:
gearman -w -f wc -- wc -l
It seems to run.
Nevertheless,
gearadmin --workers
results in something that probably represents and empty list :
33 127.0.0.1 - :
.
(In version 0.16, I was able to see 2 lines, the second showing the registered function name.)
Attempting to run the client
gearman -f wc < /etc/passwd
results in
gearman: gearman_client_run_tasks : flush(GEARMAN_COULD_NOT_CONNECT) localhost:0 -> libgearman/connection.cc:671"
This might be the very same problem described in here - the port not specified, but I have no idea how to do it through the command line tool.
Any idea?
Ok, It looks like the answer in here was the key to success. Probably, the "getting started" section was not updated for a while. Indeed, one must specify a port explicitly for gearmand and gearman .
Server:
sudo gearmand -p 5000
Worker:
gearman -p 5000 -w -f wc -- wc -l
Client:
gearman -p 5000 -f wc < /etc/passwd