I was looking if there exists a program in c/c++ which gives the process and thread information which access files within a given folder. Actually when my application is running all of sudden I am getting the "Reason = 13 (Permission denied)" for fopen() method call. I have tried googling this, but I didn't get relevant information. There is a chance of other applications also access the file. So I would like to log the process and thread information when I got the above mentioned error. I am unaware of anything which does this and would like to know if one exists.
The error says that you don't have permissions to access the file. See Traditional Unix permissions
for more details.
This error is not related to the file being used by other processes.
Related
Suppose I have a Linux executable, which fails to perform some operation with EPERM (Permission Denied) error code. I also, can track the specific API it calls with strace. Suppose also, it caused because kernel check fails on specific user or executable capability, which is needed for this operation.
Is it possible to identify, somehow, the exact capability id that failed the check in kernel and caused generic EPERM error?
Now, I know that there's man page for capability which describes in general the existing capabilities, and how to use them. Still I wonder if there's away to automatically expose the capability that has to be added.
The goal of cause is to create user or file with minimum capability set that us sufficient to perform the task.
We've been encountering an issue with a particular website hosted in iis for which I've not managed to get much information from the event log. I'm a bit out of my league with these low level 'raw' diagnostic tools and I'm not if I'm barking up the wrong tree (in which case please tell me - e.g IIS is just broken) or whether I'm following the correct paths to try and locate the issue.
A process serving application pool 'MyWebsite' suffered a fatal communication error with the Windows Process Activation Service. The process id was '4372'. The data field contains the error number.
Running with DebugView open I reliably see these lines when I encounter an issue
[5904] 4692 iisutil!ReadMultiStringParameterValueFromAnyService [helpfunc.cxx # 490]:Inetinfo: Failed reading registry value
[5904]
Error(80070002): The system cannot find the file specified.
I therefore tried installing DebugDiag and looking for any exceptions, which create a number of full dumps for me. Once I've analyzed them I've got a report out the other end shown below, but I'm not sure how to further analyse this. It tells me the type and message were NOT_FOUND and suggests contacting Microsoft. While this is 1 route - I'd like to know if there are further things that can be done before considering that approach:
I managed to find the cause of my problem, a StackOverflowException because a local reproduction was possible and it was quite apparent once the debugger was attatched.
I've therefore got to assume, that StackOverflowExceptions are similar to OutOfMemoryExceptions in that it makes IIS unstable and therefore completely unable to complete running (even to the point of providing/logging exception information).
I have a linux service (c++, with lots of loadable modules, basically .so files picked up at runtime) which from time to time crashes ... I would like to get behind this crash and investigate it, however at the moment I have no clue how to proceed. So, I'd like to ask you the following:
If a linux service crashes where is the "core" file created? I have set ulimit -c 102400, this should be enough, however I cannot find the core files anywhere :(.
Are there any linux logs that track services? The services' own log obviously is not telling me that I'm going to crash right now...
Might be that one of the modules is crashing ... however I cannot tell which one. I cannot even tell which modules are loaded. Do you know how to show in linux which modules a service is using?
Any other hints you might have in debugging a linux service?
Thanks
f-
Under Linux, processes which switch user ID, get their core files disabled for security reasons. This is because they often do things like reading privileged files (think /etc/shadow) and a core file could contain sensitive information.
To enable core dumping on processes which have switched user ID, you can use prctl with PR_SET_DUMPABLE.
Core files are normally dumped in the current working directory - if that is not writable by the current user, then it will fail. Ensure that the process's current working directory is writable.
0) Get a staging environment which mimics production as close as possible. Reproduce problem there.
1) You can attach to a running process using gdb -a (need a debug build of course)
2) Make sure the ulimit is what you think it is (output ulimit to a file from the shell script
which runs your service right before starting it). Usually you need to set ulimit in /etc/profile file; set it ulimit -c 0 for unlimited
3) Find the core file using find / -name \*core\* -print or similar
4) I think gdb will give you the list of loaded shared objects (.so) when you attach to the process.
5) Add more logging to your service
Good luck!
Your first order of business should be getting a core file. See if this answer applies.
Second, you should run your server under Valgrind, and fix any errors it finds.
Reproducing the crash when running under GDB (as MK suggested) is possible, but somewhat unlilkely: bugs tend to hide when you are looking for them, and the debugger may affect timing (especially if your server is multi-threaded).
I have the same questions as this post
Only that my question is on the Linux platform
I have a directory in my folder
and I don't know which program has created it
Is it possible to know ?
Thanks
Same answer applies, unless the file itself has metadata like some .doc files and such that contains the information you cannot know what created the file (unless you create a kernel module to intercept block requests to create new files and check what application submitted the request but that is probably not what you want to do).
The answer is the same as in the previous question -- generally, no.
However, you can look at the owner and group of this directory; if the program that creates it is a daemon (service) process, it might be running under its own user / group and thus the files / directories created might have those ownerships.
What does this say?
ls -l /path/to/the/directory
The answer is the same as the one for question you linked. Linux doesn't store information about the creator of the file as far as which program did it. But, like the other answer said, you could create a monitor and record that information yourself.
How come I always get
"GConf Error: Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See http://projects.gnome.org/gconf/ for information. (Details - 1: Failed to get connection to session: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.)"
when I start 'gedit' from a shell from my superuser account?
I've been using GUI apps as a logged-in user and as a secondary user for 15+ years on various UNIX machines. There's plenty of good reasons to do so (remote shell, testing of configuration files, running multiple sessions of programs that only allow one instance per user, etc).
There's a bug at launchpad that explains how to eliminate this message by setting the following environment variable.
export DBUS_SESSION_BUS_ADDRESS=""
The technical answer is that gedit is a Gtk+/Gnome program, and expects to find a current gconf session for its configuration. But running it as a separate user who isn't logged in on the desktop, you don't find it. So it spits out a warning, telling you. The failure should be benign though, and the editor will still run.
The real answer is: don't do that. You don't want to be running GUI apps as anything but the logged-in user, in general. And you never want to be running any GUI app as root, ever.
For some (RHEL, CentOS) you may need to install the dbus-x11 package ...
sudo yum install dbus-x11
Additional details here.
Setting and exporting DBUS_SESSION_BUS_ADDRESS to "" fixed the problem for me. I only had to do this once and the problem was permanently solved. However, if you have a problem with your umask setting, as I did, then the GUI applications you are trying to run may not be able to properly create the directories and files they need to function correctly.
I suggest creating (or, have created) a new user account solely for test purposes. Then you can see if you still have the problem when logged in to the new user account.
I ran into this issue myself on several different servers. It I tried all of the suggestions listed here: made sure ~/.dbus had proper ownership, service messagbus restart, etc.
I turns out that my ~/.dbus was mode 755 and the problem went away when I changed the mode to 700. I found this when comparing known working servers with servers showing this error.
I understand there are several different answers to this problem, as I have been trying to solve this for 3 days.
The one that worked for me was to
rm -r .gconf
rm -r .gconfd
in my home directory. Hope this helps somebody.