Re: incron fails after dealing with changes done by useradd or userdell

Hi,

Thank you Lukas. If it is of any help, I was using useradd coming from shadow version
4.1.4.3 on an x64 Gentoo system.

I can also confirm that after changing /etc/passwd to /etc in the incrontab, changes to
/etc/passwd done by useradd or userdel do not lock incrond up. I can only confirm that for
each useradd or userdel operations there are 13 changes to files in /etc - I'm not sure if
that's normal, but perhaps that's what was causing the daemon to lock up?

Patryk

On 03/08/2011 05:01 PM, Lukas Jelinek wrote:
> Hi,
> your strace's output looks strange. Please look at this one from my testing Debian
> Squeeze: http://pastebin.com/Cz3v88w1 and use 'grep' for checking what I say. You can
> see here that /etc/passwd is open for writing exactly once but nothing is written (I
> don'n know why it is done this way but it doesn't matter). The modification itself is
> done via creating /etc/passwd+ and renaming it to /etc/passwd. The same applies for
> userdel for example.
>
> It means that incron works well for it. But it is impossible to monitor such changes by
> hooking on /etc/passwd because incron inherently loses the appropriate kernel watch.
> There were some discussions about re-arming such watches (by incron) but this would be a
> dirty solution as there is inherently some delay between the given event and re-arming
> the watch.
>
> If you want to monitor such events please place the watch on the parent directory (/etc
> for here) and set the appropriate filtering, e.g. in a script. It will generate many
> commonplace events but you always get everything related to the object you need.
>
> Regards,
> Lukas
>
>> On 03/07/2011 06:37 PM, Lukas Jelinek wrote:
>>> Hi Patryk,
>>> this kind of problems was discussed many times here and almost always these problems
>>> were classified as "correct but unexpected behavior" (not a bug). Please use "strace"
>>> and send its output to the mailing list. I think useradd may behave different ways and
>>> there is no chance to move forward without more detailed information. Thanks.
>>>
>>> Lukas
>>>
>> Hi Lukas,
>>
>> Please find the strace here: http://pastebin.com/vzj3vWRr
>> Please note this contains output from launch up till useradd. There was no reaction during
>> userdel after the useradd.
>>
>> Kind regards,
>>
>> Patryk
>>
>
Received on Tue Jun 05 2012 - 22:14:21 CEST