All of lore.kernel.org
 help / color / mirror / Atom feed
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: Sun, 01 Dec 2013 20:33:59 +0100	[thread overview]
Message-ID: <529B8F27.6040202@molgen.mpg.de> (raw)
In-Reply-To: <7B07798B-AB21-4FD2-AE32-B280A8DAE045@themaw.net>

[-- Attachment #1: Type: text/plain, Size: 1921 bytes --]

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/.

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



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4541 bytes --]

  reply	other threads:[~2013-12-01 19:33 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 [this message]
2013-12-02  0:45     ` Ian Kent
2013-12-02  9:12       ` Donald Buczek
  -- 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=529B8F27.6040202@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.