-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Recursive directory create crashes incrond #25
Comments
I get a segmentation fault! :/ |
+1 same here: kernel: [183657.978993] traps: incrond[12084] general protection ip:411c23 sp:7ffd8bf27ef0 error:0 in incrond[400000+1e000] |
+1 Oct 04 17:25:35 wohn systemd-coredump[2946]: Process 2927 (incrond) of user 0 dumped core. As I have to monitor for a specific file below an unspecific directory, this is a deal breaker for me. Is this project under active development anymore? |
Same, I'm using it to detect when USB devices are automounted.
|
I am getting a similar crash if I pass a folder as part of the triggered command:
Here is my incrontab triggering the crash. Note above that files work fine. |
I just need to mkdir to make it crash
|
I have the same problem with this incron version under Gentoo Linux. Is this project sill alive? |
I experienced the same issue on Gentoo Linux, and did some cursory investigation. In I was able to work around this issue by saving the path from the inotify watch in a separate variable, and replacing the later accesses in that function with this variable: diff --git i/usertable.cpp w/usertable.cpp
index 11fd04b..8ebe3fe 100644
--- i/usertable.cpp
+++ w/usertable.cpp
@@ -370,20 +370,21 @@ void UserTable::OnEvent(InotifyEvent& rEvt)
{
InotifyWatch* pW = rEvt.GetWatch();
IncronTabEntry* pE = FindEntry(pW);
+ std::string pW_path = pW->GetPath();
// no entry found - this shouldn't occur
if (pE == NULL)
return;
// discard event if user has no access rights to watch path
- if (!(m_fSysTable || MayAccess(pW->GetPath(), DONT_FOLLOW(rEvt.GetMask()))))
+ if (!(m_fSysTable || MayAccess(pW_path, DONT_FOLLOW(rEvt.GetMask()))))
return;
//#if 0
// log output for each dir + file + event
std::string events;
rEvt.DumpTypes(events);
- syslog(LOG_INFO, "PATH (%s) FILE (%s) EVENT (%s)", pW->GetPath().c_str() , IncronTabEntry::GetSafePath(rEvt.GetName()).c_str() , events.c_str());
+ syslog(LOG_INFO, "PATH (%s) FILE (%s) EVENT (%s)", pW_path.c_str() , IncronTabEntry::GetSafePath(rEvt.GetName()).c_str() , events.c_str());
//#endif
// add new watch for newly created subdirs
@@ -422,7 +423,7 @@ void UserTable::OnEvent(InotifyEvent& rEvt)
else {
cmd.append(cs.substr(oldpos, pos-oldpos));
if (cs[px] == '@') { // base path
- cmd.append(IncronTabEntry::GetSafePath(pW->GetPath()));
+ cmd.append(IncronTabEntry::GetSafePath(pW_path));
oldpos = pos + 2;
}
else if (cs[px] == '#') { // file name I'm not sure what the proper solution is but this workaround prevents incrond from crashing for me on nested directory creation. |
I'll look for an alternative... This issue sucks a lot.im building a saas. And my platform refresh httpd config when a new setup is created (a new folder is created) however incron goes on subdirectories and crashes... |
What's under active development and maintained is systemd.path units. They have almost all the same features but don't crash. Internally, both use the kernel's inotify system AFAIK. Obviously, that's no solution for all those avoiding systemd. But everyone else should check this out. |
did that really solve? where can I make the change, for me to test? I'm using Pop-OS (Ubuntu 20.04 LTS). in my syslog it shows this:
|
hi guys, i am same problem, is incron stiil in development? |
I confirm this bug in my system too (Arch Linux) if rules in |
Works nicely for me, on Gentoo too, with sys-process/incron-0.5.12_p20191114 Thank you very much. Edit: |
If someone is looking for a backtrace,
So the trigger is really accessing the path And the reload mentioned by @smkent happens in Lines 389 to 408 in 6f4c9a2
so this code could either be moved to the end of the function (in which case the action would fire before new watchers for the new folder(s) are created) or like @smkent proposed, the value could be stored in a temporary variable which will be still available later when the old watch |
@Whissi can confirm that i don't get a segmentation fault as soon i remove the |
This works for mi too!! |
When I do
mkdir dir1
thenmkdir dir1/dir2
it crashes incrond process and I have to manually restart it.It works fine for files, just a directory within a directory.
The text was updated successfully, but these errors were encountered: