Hot answers tagged dump
Yes, sure. $ dd if=/dev/sda of=mbr bs=512 count=1 1+0 records in 1+0 records out 512 bytes (512 B) copied, 0.000188571 s, 2.7 MB/s $ stat -c %s mbr 512 $ hd mbr 00000000 eb 48 90 d0 bc 00 7c 8e c0 8e d8 be 00 7c bf 00 |.H....|......|..| 00000010 06 b9 00 02 fc f3 a4 50 68 1c 06 cb fb b9 04 00 |.......Ph.......| 00000020 bd be 07 80 7e 00 00 7c 0b ...
Use fmem You used to be able to simply dd /dev/mem back in the day, but no longer for security reasons (since kernel 2.6, IIRC). The alternative is to either build the kernel yourself wih the option to let root do that (will edit with name later, on phone now) OR better, use fmem, a kernel module which creates a /dev/fmem device pretty much meant for easy ...
Having expended far too much time with dump, it is probably best relegated to history. Its primary design goal was to be as efficient as possible with slow filesystems and the constraints of magnetic tape. Those design criteria no longer obtain and I cannot imagine a situation (aside from legacy systems) where dump would provide any advantage.
For 14.04 you can just install postgresql-client-9.3 (as it depends on postgresql-client-common): sudo apt-get install postgresql-client-9.3 To quickly know which package contains a command/binary missing on your system, just use package.ubuntu.com (Search the contents of packages).
dump is traditionally used in cases where you need to image an entire device once, and not keep backing it up incrementally. Since it was created in a time where magnetic tapes were popular, random disk writes were not all that possible, making incremental backups nearly impossible. rsync is a more robust tool that doesn't try to account for those obsolete ...
Try making a separate wrapper bash script with the commands between script and end script and pass that to an exec option in the same upstart file. Chance are that whatever ulimit -c 10000 does disappears by the time upstart calls ./myapp. Also note that it isn't quite correct to name your file "upstart script". It is a configuration file. It may happen to ...
One solution from over on ServerFault direct quote: I've made a script that accomplishes this task. The idea commes from James Lawrie's answer and this post: http://www.linuxforums.org/forum/programming-scripting/52375-reading-memory-other-processes.html#post287195 #!/bin/bash grep rw-p /proc/$1/maps | sed -n 's/^\([0-9a-f]*\)-\([0-9a-f]*\) .*$/\1 \2/p'...
The problem was with SublimeCodeIntel package. Just move(or remove) it outside of Packages folder: mv <path to sublime-text>/Packages/SublimeCodeIntel ~/ Then run Sublime Text and re-install SublimeCodeIntel from PackageControl: Ctrl+Shift+P -> Package Control: Install Package -> SublimeCodeIntel.
I am guessing that you are running the crashing process as root. If that is the case, change the domain from '*' to 'root'. The limit.conf lines that contain the wildcard (a.k.a. '*') does not affect the 'root' account.
In addition to the proposed answer I would also suggest to use simply hd: sudo hd /dev/sda -n 512 -s 0x0 00000000 eb 48 90 d7 bc 00 7a bb a0 07 8e db 8e c3 be 00 |.H....z.........| 00000010 02 8b ce fc f3 a4 ea a3 00 a0 07 b9 04 00 8b fd |................| 00000020 80 3d 80 74 05 83 c7 10 e2 f6 c3 b9 04 00 8b f5 |.=.t............| 00000030 88 2c ...
You probably can't dd your memory in modern kernels cause they've been reducing direct access, which is mostly used for dodgy things. The forensics wiki links a few tools that might be of interest, but there's nothing that's really been updated in the past few years. LiME seems updated though I haven't tested it yet.
Backup MYSQL DB on one server and restore on other, do i need the same version of MYSQL? It is preferred but not required. If there is an issue between releases you will be notified though (and with a message that states their is a problem with a specific command or table). The dump contains all the files for exported database but does not create the ...
Found the culprit: root@vmhost:~# grep -Ri crashkernel /etc/* /etc/default/grub.d/kexec-tools.cfg:GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=384M-:128M" Thanks to @Jan! I didn't know that GRUB has additional config in /etc/default/grub.d. After removing this file, crashkernel is not being added anymore. Seems it belongs to kexec-...
The file configuration file you're looking for is actually in /etc/default/grub.d/kexec-tools.cfg. Just modify that file and change crashkernel to: crashkernel=<xxx>M Then run: update-grub And reboot.
The following should work equally well. description "myupstart" start on runlevel  stop on runlevel [!2534] limit core 10000 10000 chdir /path/to/myapp pre-start script echo "/var/crash/core.%e.%s.%u.%g.%p.%t" > /proc/sys/kernel/core_pattern end script exec /path/to/app/myapp
That's what it's supposed to do. It could take a very long time for a server to dump ram, and depend on your host they may "catch" it and do something odd with it. My advise, "quit messin' with it". The command triggers a kernel panic. Nothing more. All that extra stuff, is configurable and not really reliable. Your hosting provider may catch it (...
I did the same command and that cause me a kernel panic. So decide to google it and find some interesting information. We are causing a kernel test crash when we execute this command echo c | sudo tee /proc/sysrq-trigger According to the ubuntu documentation If everything works, there should be some delay (depending on the memory size). Then the ...
/etc/security/limits.conf sets the limits, not the defaults. To actually use it you have to run ulimit -c unlimited in the shell you are using. As with any shell commands to be run in every shell, this can be put in, for example, ~/.bashrc (per user) or /etc/bash.bashrc (all users).
In addition to the other answers, rsync's ability to run on most operating systems (even telephones!) and it's sheer ubiquity and popularity make it my choice.
Only top voted, non community-wiki answers of a minimum length are eligible