From: Donald Buczek <buczek@molgen.mpg.de>
To: Ian Kent <raven@themaw.net>
Cc: "autofs@vger.kernel.org" <autofs@vger.kernel.org>
Subject: Re: expire after kill -HUP ?
Date: Mon, 02 Dec 2013 10:12:24 +0100 [thread overview]
Message-ID: <529C4EF8.5060305@molgen.mpg.de> (raw)
In-Reply-To: <1385945107.2507.1.camel@perseus.fritz.box>
Yeah, the patch fixed it. Thank you!
Donald
On 12/02/13 01:45, Ian Kent wrote:
> On Sun, 2013-12-01 at 20:33 +0100, Donald Buczek wrote:
>> Hello,
>>
>> sorry, I kept it short because I hoped, you might be able to reproduce
>> it easily.
>>
>> The output of http://owww.molgen.mpg.de/~buczek/autofs-demo/AAA_test.sh
>> is in http://owww.molgen.mpg.de/~buczek/autofs-demo/AAA_test.log.
>> Clearly the expiry stops after the first HUP. Maps not changed. The two
>> config files are also in http://owww.molgen.mpg.de/~buczek/autofs-demo/.
> Maybe I don't see it because I'm running with this patch ....
> https://www.kernel.org/pub/linux/daemons/autofs/v5/patches-5.0.9/autofs-5.0.8-fix-task-manager-not-getting-signaled.patch
>
> Can you give it a try please.
>
>> Thank you !
>> Donald
>>
>> Am 01.12.2013 08:21, schrieb Ian Kent:
>>>> On 30 Nov 2013, at 6:11 pm, Donald Buczek <buczek@molgen.mpg.de> wrote:
>>>>
>>>> Hello,
>>>>
>>>> autofs-5.0.8
>>>> kernel 3.8.2
>>>>
>>>> I've noticed, that in our installation mounts stop expiring after we send the daemon a SIGHUP to notify it about map updates.
>>> I don't see that here.
>>>
>>>> Debug log from the daemon seems to confirm that, the regular "st_expire: state 1 path... " messages no longer appear after the HUP is received and processed ("re-reading master map"...).
>>>>
>>> There have been a couple of changes in that area, I'll have a look around.
>>> Can you give a bit more detail about the problem like:
>>> does it happen the very first time every time.
>>> are there specific changes that trigger the behaviour.
>>> does it happen if no changes are actually made.
>>> what sort of activity is happening when the problem occurs.
>>>
>>> and a look at the log would probably be useful.
>>>
>>>
>>>> Maybe the signal goes to the st_queue_handler task?
>>> The signal goes to the main thread and the thread is responsible for adding tasks to the task queue as needed.
>>>
>>> That's pretty much only for readmap and program exit, but alarms (which trigger the expire runs) are cleared and set at various places, mostly at the start and end of expire run.
>>>
>>>> Regards
>>>> Donald Buczek
>>>>
>>>> --
>>>> Donald Buczek
>>>> buczek@molgen.mpg.de
>>>> Tel: +49 30 8413 1433
>>>>
>>>>
>>>>
>>
>
--
Donald Buczek
buczek@molgen.mpg.de
Tel: +49 30 8413 1433
next prev parent reply other threads:[~2013-12-02 9:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-30 10:11 expire after kill -HUP ? Donald Buczek
2013-12-01 7:21 ` Ian Kent
2013-12-01 19:33 ` Donald Buczek
2013-12-02 0:45 ` Ian Kent
2013-12-02 9:12 ` Donald Buczek [this message]
-- strict thread matches above, loose matches on Subject: below --
2013-11-29 22:50 Donald Buczek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=529C4EF8.5060305@molgen.mpg.de \
--to=buczek@molgen.mpg.de \
--cc=autofs@vger.kernel.org \
--cc=raven@themaw.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.