* expire after kill -HUP ?
@ 2013-11-30 10:11 Donald Buczek
2013-12-01 7:21 ` Ian Kent
0 siblings, 1 reply; 6+ messages in thread
From: Donald Buczek @ 2013-11-30 10:11 UTC (permalink / raw)
To: autofs
[-- Attachment #1: Type: text/plain, Size: 519 bytes --]
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.
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"...).
Maybe the signal goes to the st_queue_handler task?
Regards
Donald Buczek
--
Donald Buczek
buczek@molgen.mpg.de
Tel: +49 30 8413 1433
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4541 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: expire after kill -HUP ?
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
0 siblings, 1 reply; 6+ messages in thread
From: Ian Kent @ 2013-12-01 7:21 UTC (permalink / raw)
To: Donald Buczek; +Cc: autofs@vger.kernel.org
> 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
>
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: expire after kill -HUP ?
2013-12-01 7:21 ` Ian Kent
@ 2013-12-01 19:33 ` Donald Buczek
2013-12-02 0:45 ` Ian Kent
0 siblings, 1 reply; 6+ messages in thread
From: Donald Buczek @ 2013-12-01 19:33 UTC (permalink / raw)
To: Ian Kent; +Cc: autofs@vger.kernel.org
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: expire after kill -HUP ?
2013-12-01 19:33 ` Donald Buczek
@ 2013-12-02 0:45 ` Ian Kent
2013-12-02 9:12 ` Donald Buczek
0 siblings, 1 reply; 6+ messages in thread
From: Ian Kent @ 2013-12-02 0:45 UTC (permalink / raw)
To: Donald Buczek; +Cc: autofs@vger.kernel.org
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
> >>
> >>
> >>
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: expire after kill -HUP ?
2013-12-02 0:45 ` Ian Kent
@ 2013-12-02 9:12 ` Donald Buczek
0 siblings, 0 replies; 6+ messages in thread
From: Donald Buczek @ 2013-12-02 9:12 UTC (permalink / raw)
To: Ian Kent; +Cc: autofs@vger.kernel.org
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* expire after kill -HUP ?
@ 2013-11-29 22:50 Donald Buczek
0 siblings, 0 replies; 6+ messages in thread
From: Donald Buczek @ 2013-11-29 22:50 UTC (permalink / raw)
To: autofs
[-- Attachment #1: Type: text/plain, Size: 516 bytes --]
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.
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"...).
Maybe the signal goes to the st_queue_handler task?
Regards
Donald Buczek
--
Donald Buczek
buczek@molgen.mpg.de
Tel: +49 30 8413 1433
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4541 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-12-02 9:12 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
-- strict thread matches above, loose matches on Subject: below --
2013-11-29 22:50 Donald Buczek
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.