Bug 432351 - Direct maps fail on startup with autofs-5.0.1-0.rc2.55.el5.3
Direct maps fail on startup with autofs-5.0.1-0.rc2.55.el5.3
Status: CLOSED NEXTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: autofs (Show other bugs)
5.1
i386 Linux
low Severity medium
: rc
: ---
Assigned To: Ian Kent
Brock Organ
GSSApproved
: ZStream
Depends On: 336961
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-11 10:07 EST by Shad L. Lords
Modified: 2008-05-29 10:41 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-29 10:41:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Requested information (2.20 KB, text/plain)
2008-02-11 12:32 EST, Shad L. Lords
no flags Details
Patch to fix incorrect initialization, causing unpredictable behavior. (689 bytes, patch)
2008-02-12 21:49 EST, Ian Kent
no flags Details | Diff

  None (edit)
Description Shad L. Lords 2008-02-11 10:07:01 EST
Description of problem:

After updateing from autofs-5.0.1-0.rc2.55.el5.2 to autofs-5.0.1-0.rc2.55.el5.2
direct mounts fail to be created on startup.  After issuing a -HUP to automount
the direct mounts start to function

How reproducible:

Always

Steps to Reproduce:
1. install autofs-5.0.1-0.rc2.55.el5.3
2. create direct maps for autofs (file or ldap based)
3. issue -HUP to get them to start functioning
  
Actual results:

Direct maps don't showup or work until a HUP is sent to automount

Expected results:

Direct maps should work as soon as the autofs daemon is started.

Additional info:

When run with both verbose and debugging direct maps don't showup.  However on
shutdown it shows that it is shutting down path /-.  Upon issuing a HUP is shows
mounted direct mount on ... and then stopping the daemon shows unmounting direct
mount ... along with the shutting down path /-.
Comment 1 Ian Kent 2008-02-11 10:47:38 EST
This is very strange as the change in the update isn't
related to the code that handles direct maps at all.

Can you post the information described at
http://people.redhat.com/jmoyer so we can check try and
spot what might be happening.

Ian
Comment 2 Shad L. Lords 2008-02-11 12:32:57 EST
Created attachment 294581 [details]
Requested information
Comment 3 Shad L. Lords 2008-02-11 12:35:48 EST
(In reply to comment #1)
> This is very strange as the change in the update isn't
> related to the code that handles direct maps at all.

Changelog disagrees with this:

* Mon Jan 21 2008 Ian Kent <ikent@redhat.com> - 5.0.1-0.rc2.55.el5.3
- Bug 429163 Processed: Reloading autofs map incorrectly removes all map entries
- add patches to prevent direct map being incorrectly marked stale.
- Resolves: rhbz#429163

It specifically states that patches were added dealing with direct maps.
Comment 4 Shad L. Lords 2008-02-11 12:37:39 EST
One additional thing I just found is that if I change auto.master from:

/- auto.direct

to:

/- /etc/auto.direct

then it does what it is supposed to do.
Comment 5 Ian Kent 2008-02-11 20:52:06 EST
(In reply to comment #3)
> Changelog disagrees with this:
> 
> * Mon Jan 21 2008 Ian Kent <ikent@redhat.com> - 5.0.1-0.rc2.55.el5.3
> - Bug 429163 Processed: Reloading autofs map incorrectly removes all map entries
> - add patches to prevent direct map being incorrectly marked stale.
> - Resolves: rhbz#429163

Ha, sorry, forgot about that one.
My mistake.

Ian
Comment 6 Ian Kent 2008-02-11 20:53:35 EST
(In reply to comment #4)
> One additional thing I just found is that if I change auto.master from:
> 
> /- auto.direct
> 
> to:
> 
> /- /etc/auto.direct
> 
> then it does what it is supposed to do.

OK, that should be easy enough to reproduce.
I'll need to put something in the regression tests
to check for that as well.

Ian


Comment 7 Ian Kent 2008-02-11 21:15:46 EST
Yes, I've been able to duplicate this.
The problem doesn't exist with revision 0.rc2.86 which
is the revision from which these patches were taken.

There's a dependency that's not obvious.
I'll get onto it straight away.
Sorry for the inconvenience.

Ian
Comment 8 Ian Kent 2008-02-12 01:39:05 EST
This really bazaar.

This looks like an variable initialization problem.

As far as I can tell there is no difference in the compile
options between 0.rc2.86 and 0.rc2.55.el5.3 and yet
0.rc2.55.el5.3 always gets a zero in the uninitialized
field in question whereas 0.rc2.86 always gets garbage
(which is the same as 1, as it should be at this point).

So, it's a bug in revision 86 as well.
Ian
Comment 9 Ian Kent 2008-02-12 21:49:03 EST
Created attachment 294719 [details]
Patch to fix incorrect initialization, causing unpredictable behavior.

Although the issue, and resolution, seems quite
clear to me it would be good if this patch could
be tested.
Comment 10 Shad L. Lords 2008-02-12 21:57:17 EST
If you can get a test rpm built I'll be able to test it for you.  I've got a
number of machines that exhibit this error and it will be very obvious if it is
fixed or not.
Comment 11 Shad L. Lords 2008-02-12 21:58:26 EST
(In reply to comment #8)
> This looks like an variable initialization problem.
> 
> As far as I can tell there is no difference in the compile
> options between 0.rc2.86 and 0.rc2.55.el5.3 and yet
> 0.rc2.55.el5.3 always gets a zero in the uninitialized
> field in question whereas 0.rc2.86 always gets garbage
> (which is the same as 1, as it should be at this point).
> 
> So, it's a bug in revision 86 as well.

Can you also check the el5.2 as that one functions fine for me.  Interested to
know if that initializes to garbage or 0 too.
Comment 12 Ian Kent 2008-02-12 23:22:39 EST
(In reply to comment #11)
> (In reply to comment #8)
> > This looks like an variable initialization problem.
> > 
> > As far as I can tell there is no difference in the compile
> > options between 0.rc2.86 and 0.rc2.55.el5.3 and yet
> > 0.rc2.55.el5.3 always gets a zero in the uninitialized
> > field in question whereas 0.rc2.86 always gets garbage
> > (which is the same as 1, as it should be at this point).
> > 
> > So, it's a bug in revision 86 as well.
> 
> Can you also check the el5.2 as that one functions fine for me.  Interested to
> know if that initializes to garbage or 0 too.
> 

I'll check but I'm not sure how useful that will be because
it should be random, although it doesn't appear to be.

Also, the change that caused it alters the way autofs decides
whether to read the map.

Ian
Comment 13 Ian Kent 2008-02-12 23:41:41 EST
It's interesting to note that, after looking at the test
I wrote for this bug, it will catch the bad initialization
and fail if it happens. But, of course, it doesn't seem to
happen in packages on the main CVS branch.

Odd and odder!
Comment 14 Ian Kent 2008-02-13 00:09:19 EST
I've just checked out, built and tested rev 0.rc.55.2 and it
gets a zero and not garbage and so works as it should.

I still can't see any difference in the package build.

The field in question belongs to a structure allocated
on the stack (in this case) so it really should be
initialized correctly by me.

Ian
Comment 15 Ian Kent 2008-02-13 00:19:10 EST
(In reply to comment #10)
> If you can get a test rpm built I'll be able to test it for you.  I've got a
> number of machines that exhibit this error and it will be very obvious if it is
> fixed or not.

Policy is that all changes made available to customers need
to be tracked in CVS. So I'll need get an ack for the rhel-5.1.z
flag before I can commit this and build the rpm.

I'll see what I can do this evening.
Ian
Comment 16 Shad L. Lords 2008-03-20 10:11:53 EDT
Has there been any progress on this?
Comment 17 Ian Kent 2008-03-20 11:14:18 EDT
(In reply to comment #16)
> Has there been any progress on this?

No ACKS, so I can't do anything.

But I think there is more to this than just the patch I
posted.

If the people with the ability provide the ACKS below, I'll
investigate what else is needed. It is always risky when only
a small part of the changes contained in a later release are
applied to fix a problem in an earlier release.

You could test the RHEL 5.2 beta.

Ian
Comment 23 Jiri Skrabal 2008-05-29 10:41:50 EDT
Closing this with resolution NEXTRELEASE since this is already fixed in 5.2
release and the 5.1.z stream is cancelled.

Note You need to log in before you can comment on or make changes to this bug.