I'm working on AIX and have a process that keeps crashing. I've never examined core files, and would like some guidance if possible. I'm using dbx. How can I (a) make sure the core file is going where I want it to go and (b) see the state of the process before it crashed?
Thanks!
I do okay stepping through a run but also am not sure about debugging a core.
I found these commands are probably the ones to focus on. There are probably more.
Once you have your core running in dbx:
'where' -- to show the stack
'up' or 'down' -- to move through the frames and then you
'print var' -- display the variables
and 'list' or 'edit' -- will display the file information at that current location
Looking here under "Examining Data" helped me out.
core files are created in the current working directory of a process. Check with getcwd(), set with chdir().
dbx [ -a ProcessID ] [ -B DebugFile ] [ -c CommandFile ] [ -I Directory ] [ -E DebugEnvironment ] [ -p oldpath=newpath:...| pathfile ] [ -u ] [ -F ] [ -r ] [ -x ] [ -v ] [ -C CoreFile | ObjectFile [ CoreFile ] ]
Load your program into dbx with dbx /path/to/progname /path/to/corefile and you can start looking at your stack trace ("where" command, etc).
If you don't specify a corefile dbx will automatically load a matching file named "core" if its in the same directory as the program loaded (and they match signatures).
Read the man page on dbx, it gives all the debugging commands you'll need.
Also note that your program will have needed to be compiled with debugging symbols enabled (and not later 'strip'ed) in order for the stack trace to be the most useful. Without debugging symbols you'll see the function names in the stack trace, but not much else.
Related
I am trying to generate a debian package via cpack that respects the system configuration (as in don't start the service if the admin doesn't want it to) and that does not cause errors when being installed in a systemd free environment (as in some docker images).
My current setup consist out of a postinst and a prerm file that are simple given to cpack via CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA.
These call systemctl enable/start/stop/disable in both scripts.
From what I have gathered one should call dh_installsystemd --name=foo foo.service for starting services.
Replacing systemctl enable foo.service with that in my postinst file however causes an error:
dh_installsystemd: error: "debian/control" not found. Are you sure you are in the correct directory?
dpkg: error processing package foo (--configure):
installed foo package post-installation script subprocess returned error exit status 255
Processing triggers for libc-bin (2.31-0ubuntu9.2) ...
Errors were encountered while processing:
foo
I must confess that I am somewhat lost as to how this should be handled.
How does one correctly add a systemd service to a debian package via CPack?
The best solution that has come to mind is to dissect another package and use the same commands dh_installsystemd generates.
This results in a postinst file like:
# End automatically added section
# Based on output by dh_installsystemd/13.5.2
if [ \"$1\" = \"configure\" ] || [ \"$1\" = \"abort-upgrade\" ] || [ \"$1\" = \"abort-deconfigure\" ] || [ \"$1\" = \"abort-remove\" ] ; then
# was-enabled defaults to true, so new installations run enable.
if deb-systemd-helper --quiet was-enabled 'foo.service'; then
# Enables the unit on first installation, creates new
# symlinks on upgrades if the unit file has changed.
deb-systemd-helper enable 'foo.service' >/dev/null || true
else
# Update the statefile to add new symlinks (if any), which need to be
# cleaned up on purge. Also remove old symlinks.
deb-systemd-helper update-state 'foo.service' >/dev/null || true
fi
fi
if [ \"$1\" = \"configure\" ] || [ \"$1\" = \"abort-upgrade\" ] || [ \"$1\" = \"abort-deconfigure\" ] || [ \"$1\" = \"abort-remove\" ] ; then
if [ -z \"${DPKG_ROOT\:-}\" ] && [ -d /run/systemd/system ]; then
systemctl --system daemon-reload >/dev/null || true
deb-systemd-invoke restart 'foo.service' >/dev/null || true
fi
fi
Since these instructions are static updates in the macros have to be manually applied.
I'm using Budo to develop a website using Browserify and Babelify like this:
budo src/index.js:static/bundle.js --live -- -t [ babelify --presets [ es2015 ] ]
That works great, except the generated static/bundle.js isn't actually saved to disk - it's just accessible in the browser. If I remove the path argument:
budo --live -- -t [ babelify --presets [ es2015 ] ]
Then it just serves a local file in static/bundle.js but doesn't regenerate it.
How do I get it to actually generate and save the file?
I'm sure you've moved onto other things, but why would you want to save it to disk anyway?
But take a look at this build file I created if you really need to:
build.js
It's my first time doing something with bash-programming. As a first example I'm trying to source my .bashrc from my .bash_profile - even when ~/.bashrc is a symbolic link.
.bash_profile:
if [ -f ~/.bashrc ] && ! [ -L ~/.bashrc ]
then
# ~/.bashrc is a regular file. Source it!
source ~/.bashrc
echo "~/.bashrc found."
elif [ -L ~/.bashrc ]
then
# ~/.bashrc is a symbolic link.
# Recursivly follow symbolic links.
location="~/.bashrc"
while [ -L $location ]
do
# QUESTION: Control-Flow never reaches this point.
# Follow link on macOS.
location="$(readlink $path)"
done
# Check if final target is regular file. Source it!
if [ -f $location ]
then
source $location
echo "Symlink to .bashrc found."
fi
else
echo "No valid .bashrc found."
fi
This is what I expect my code to do:
If ~/.bashrc is not a symbolic link, but a regular file: Source it.
Otherwise if ~/.bashrc is a symbolic link:
Follow the symbolic link as long as the target keeps being a symbolic link.
If the final target is a regular file: Source it.
Otherwise: Give it up.
As a test I created a symbolic link ~/.bashrc to the original file .dotfiles/.bashrc. My code enters the elif as intended, but sadly never enters the body of the while-loop (as I would expect, since ~/.bashrc is a symbolic link).
What is going on here? I think the variable assignment of location is wrong in some way.
Replace:
location="$(readlink $path)"
With:
location="$(readlink $location)"
Notes:
The variable path was never defined. I believe that you intended to apply readlink to location instead
If you had GNU readlink (available on Linux, homebrew, etc), then the option -f could be used eliminating the need for a loop.
In general, shell variables should be referenced inside double-quotes unless one wants the shell to apply word splitting, tilde expansion, and pathname expansion to the value of the variable.
For example, in the following line, we want tilde expansion. So, ~/ needs to be outside of quotes:
location=~/.bashrc
Once this is done, the parts of the script where location is referenced should be in double-quotes. As one example:
location="$(readlink "$location")"
This becomes very important, for example, if file or path names contains spaces.
This causes the problem:
location="~/.bashrc"
The tilde expansion doesn't happen in double quotes, and it doesn't happen in
[ -L $location ]
either.
So, don't use double quotes in the assignment, or use
location="$HOME/.bashrc"
or similar.
My default login shell is bash. From a few online forums, I configured my terminal to auto load my .bashrc file whenever I open the terminal by adding:
source ~/.bashrc in .bash_profile OR
by adding the following code snippet in .profile:
if [ -n "$BASH_VERSION" ]; then
if [ -f "$HOME/.bashrc" ]; then
. "$HOME/.bashrc"
fi
fi
With either of the two, my .bashrc loads automatically, but with this I am unable to see the process status using ps command.
Note: If I disable the auto loading of my .bashrc and manually load it by typing bash, I am still able to see process status using the ps command.
Please help me out.
You can see what ps is mapped to by typing type ps. Compare before and after the source and you should be able to re-alias it what you're expecting.
somebody knows what does this error mean?
Usage: tcsh [ -bcdefilmnqstvVxX ] [ argument ... ].
I receive this error after I enter in my script this row
#! /bin/tcsh -f
That doesn't seem like an actual error. If there would be an error bash should have said something like bash: error importing function definition for `module' what Linux System are you running on the shell? There's often documentation on error messages try command error info or browse the manual by command man -h.