src.conf ignored; phantom named

[Rotate 13]

I set WITHOUT_BIND="yes" in /etc/src.conf, and built/installed world.
Not only does /usr/sbin/named exist - named is actually started!
Several other WITHOUT_* variables also were apparently ignored, as
evidenced by stuff installed on running system.

My main question is - how do I debug this? I have been combing over
makefiles under /usr/src (not to mention, going through /etc/rc.d/
trying to figure out what actually started named). As far as I
ascertain, _WITHOUT_SRCCONF is *not* set anywhere for world building;
named_enable="no" in relevant rc.conf files; rpcbind and ntpd are not
running either. Since named daemonized, it's not easy to tell who
started it - and grepping everything in sight, I can't figure out how
it got built in the first place.

uname -a:
FreeBSD xyz.example.com 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Thu Feb 29
10:28:17 CST 2012 ro...@xyz.example.com:/usr/obj/usr/src/sys/CUSTOM
amd64

I focused substantial attention on /usr/src/share/bsd.own.mk and
worked outward; but did not find anything obvious.

Advice on where to poke for the right information, much appreciated.
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"

[Gary Palmer]

On Fri, Mar 02, 2012 at 05:41:28PM -0500, Rotate 13 wrote:
> I set WITHOUT_BIND="yes" in /etc/src.conf, and built/installed world.
> Not only does /usr/sbin/named exist - named is actually started!
> Several other WITHOUT_* variables also were apparently ignored, as
> evidenced by stuff installed on running system.
>
> My main question is - how do I debug this? I have been combing over
> makefiles under /usr/src (not to mention, going through /etc/rc.d/
> trying to figure out what actually started named). As far as I
> ascertain, _WITHOUT_SRCCONF is *not* set anywhere for world building;
> named_enable="no" in relevant rc.conf files; rpcbind and ntpd are not
> running either. Since named daemonized, it's not easy to tell who
> started it - and grepping everything in sight, I can't figure out how
> it got built in the first place.
>
> uname -a:
> FreeBSD xyz.example.com 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Thu Feb 29
> 10:28:17 CST 2012 ro...@xyz.example.com:/usr/obj/usr/src/sys/CUSTOM
> amd64
>
> I focused substantial attention on /usr/src/share/bsd.own.mk and
> worked outward; but did not find anything obvious.
>
> Advice on where to poke for the right information, much appreciated.

Does the datestamp on /usr/sbin/named reflect when you built the world
or could named have been left over from a previous install?

WITHOUT_BIND="yes" doesn't delete named if its already installed (not sure
if 'make delete-old' cleans it up or not)

As for named running, if you do

sh /etc/rc.d/named restart

does it succeed? If so, the 'named_enable="no"' flag must be set wrong.
Also check to make sure that its not named from ports or some other
location (e.g. check fstat or lsof or something to make sure its actually
/usr/sbin/named and not from some other location)

Regards,

Gary

[Dimitry Andric]

On 2012-03-02 23:41, Rotate 13 wrote:
> I set WITHOUT_BIND="yes" in /etc/src.conf, and built/installed world.
> Not only does /usr/sbin/named exist - named is actually started!
> Several other WITHOUT_* variables also were apparently ignored, as
> evidenced by stuff installed on running system.

Have you run "make delete-old" and "make delete-old-libs" after
installing world? You will have to do this the first time, to properly
get rid of all the stuff you disabled using WITHOUT_XXX settings.

[David Cornejo]

check the timestamp on /usr/sbin/named, I bet it's old as make world
doesn't delete old stuff.

I think "make delete-old" in /usr/src might do that for you.

dave c

[Yuri Pankov]

On Fri, 2 Mar 2012 17:41:28 -0500, Rotate 13 wrote:

> I set WITHOUT_BIND="yes" in /etc/src.conf, and built/installed world.
> Not only does /usr/sbin/named exist - named is actually started!
> Several other WITHOUT_* variables also were apparently ignored, as
> evidenced by stuff installed on running system.
>
> My main question is - how do I debug this? I have been combing over
> makefiles under /usr/src (not to mention, going through /etc/rc.d/
> trying to figure out what actually started named). As far as I
> ascertain, _WITHOUT_SRCCONF is *not* set anywhere for world building;
> named_enable="no" in relevant rc.conf files; rpcbind and ntpd are not
> running either. Since named daemonized, it's not easy to tell who
> started it - and grepping everything in sight, I can't figure out how
> it got built in the first place.
>
> uname -a:
> FreeBSD xyz.example.com 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Thu Feb 29
> 10:28:17 CST 2012 ro...@xyz.example.com:/usr/obj/usr/src/sys/CUSTOM
> amd64
>
> I focused substantial attention on /usr/src/share/bsd.own.mk and
> worked outward; but did not find anything obvious.
>
> Advice on where to poke for the right information, much appreciated.

src.conf controls what is (not) built. To actually remove the bits
marked as WITHOUT_ from the system, try running `make delete-old` in
/usr/src.

[Rotate 13]

On Fri, 02 Mar 2012 18:16:45 -0500, Gary Palmer <gpa...@freebsd.org> wrote:

> Does the datestamp on /usr/sbin/named reflect when you built the world
> or could named have been left over from a previous install?
>
> WITHOUT_BIND="yes" doesn't delete named if its already installed (not
> sure
> if 'make delete-old' cleans it up or not)

"stat /usr/sbin/named" leaves me in shame - yes, it is left over from
a previous buildworld. (Thanks also to others, whose suggestion of
same problem just came in from where I sit.) On to next problem...

> As for named running, if you do
>
> sh /etc/rc.d/named restart
>
> does it succeed? If so, the 'named_enable="no"' flag must be set wrong.

"sh /etc/rc.d/named restart" gives exactly what you would expect
("Cannot `restart` named. Set named_enable to YES...").

> Also check to make sure that its not named from ports or some other
> location (e.g. check fstat or lsof or something to make sure its actually
> /usr/sbin/named and not from some other location)

"fstat | grep /named" returns nothing (!), likewise "fstat | grep
/sbin". However:

# procstat -b `pgrep named`
PID COMM PATH
63121 named /usr/sbin/named
63090 named /usr/sbin/named

(I also never used ports BIND.)

I would really like to figure this out before I do the necessary work
to remove unwanted BIND from the system. Processes running without
apparent reason, indicates something else is wrong.

Thanks for the help so far. I am continuing to poke the system, just
looking for the right tool to find out how this got started (also
grepping logs which show start but don't seem to show why).

[Gary Palmer]

On Fri, Mar 02, 2012 at 06:48:12PM -0500, Rotate 13 wrote:
> > As for named running, if you do
> >
> > sh /etc/rc.d/named restart
> >
> > does it succeed? If so, the 'named_enable="no"' flag must be set wrong.
>
> "sh /etc/rc.d/named restart" gives exactly what you would expect
> ("Cannot `restart` named. Set named_enable to YES...").
>
> > Also check to make sure that its not named from ports or some other
> > location (e.g. check fstat or lsof or something to make sure its actually
> > /usr/sbin/named and not from some other location)
>
> "fstat | grep /named" returns nothing (!), likewise "fstat | grep
> /sbin".

fstat only shows the inode number of the file, e.g.

fstat -p 1283 | egrep '(^USER|text)'
USER CMD PID FD MOUNT INUM MODE SZ|DV R/W
bind named 1283 text /usr 333873 -r-xr-xr-x 1659284 r
% ls -i /usr/sbin/named
333873 /usr/sbin/named

> However:
>
> # procstat -b `pgrep named`
> PID COMM PATH
> 63121 named /usr/sbin/named
> 63090 named /usr/sbin/named
>
> (I also never used ports BIND.)
>
> I would really like to figure this out before I do the necessary work
> to remove unwanted BIND from the system. Processes running without
> apparent reason, indicates something else is wrong.
>
> Thanks for the help so far. I am continuing to poke the system, just
> looking for the right tool to find out how this got started (also
> grepping logs which show start but don't seem to show why).

I don't recall seeing in your original message - after the installworld,
did you reboot? Does "ps auxww | grep named" show that the process
predates your installworld? (The 9th column should show when the process
started, from memory)

If the named rc.d file shows that the flag is set correctly to disable
named I'm not sure what else would start it.

I'm also curious as to why two instances of named appear to be running.
On the face of it that would appear to be broken as only one could bind
to port 53. You're not running jails or anything similar are you?

Gary

[Rotate 13]

On Fri, 02 Mar 2012 19:26:08 -0500, Gary Palmer <gpa...@freebsd.org> wrote:

> fstat only shows the inode number of the file, e.g. [...]

Oops. I should have paid more attention (or installed sysutils/lsof)
before piping around output of an unfamiliar tool...

> I don't recall seeing in your original message - after the installworld,
> did you reboot? Does "ps auxww | grep named" show that the process
> predates your installworld? (The 9th column should show when the process
> started, from memory)

The system was rebooted twice since installworld, while testing
different things.

Unfortunately, the system panicked while I was digging around (seemed
hardware-related; I do not think this was related to the original
problem). When it came up, named was not running. I do need the
machine to actually work, so I dumped the filesystems with system
stuff (/usr, /var, /etc...) and started nuking/rebuilding a clean
install. Maybe I will someday poke around the dumps and find
something, but at this point I suspect it is either serious
configuration error (PEBKAC) or something else not FreeBSD's fault.

> I'm also curious as to why two instances of named appear to be running.
> On the face of it that would appear to be broken as only one could bind
> to port 53. You're not running jails or anything similar are you?

No jails. dmesg had repeated messages about inability to bind ports -
that's what gave me the clue that named was running in the first
place. I was experimenting with a variety of dnsware, and dnsmasq was
peacefully occupying 53 udp. So, neither named process was able to
bind (no pun intended). And named was obviously started significantly
after boot...

Thanks for all the help. I wish this came out more usefully for the
archives - but it seems to be wind up as a combination of "luser
forgot to make delete-old" and "bizarre, unsolved UNIX mystery".

[Chris Rees]

On 2 March 2012 23:09, Yuri Pankov <yuri....@gmail.com> wrote:
> On Fri, 2 Mar 2012 17:41:28 -0500, Rotate 13 wrote:
>
>> I set WITHOUT_BIND="yes" in /etc/src.conf, and built/installed world.
>> Not only does /usr/sbin/named exist - named is actually started!
>> Several other WITHOUT_* variables also were apparently ignored, as
>> evidenced by stuff installed on running system.
>>
>> My main question is - how do I debug this?  I have been combing over
>> makefiles under /usr/src (not to mention, going through /etc/rc.d/
>> trying to figure out what actually started named).  As far as I
>> ascertain, _WITHOUT_SRCCONF is *not* set anywhere for world building;
>> named_enable="no" in relevant rc.conf files; rpcbind and ntpd are not
>> running either.  Since named daemonized, it's not easy to tell who
>> started it - and grepping everything in sight, I can't figure out how
>> it got built in the first place.
>>
>> uname -a:
>> FreeBSD xyz.example.com 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Thu Feb 29
>> 10:28:17 CST 2012    ro...@xyz.example.com:/usr/obj/usr/src/sys/CUSTOM
>> amd64
>>
>> I focused substantial attention on /usr/src/share/bsd.own.mk and
>> worked outward; but did not find anything obvious.
>>
>> Advice on where to poke for the right information, much appreciated.
>
>
> src.conf controls what is (not) built. To actually remove the bits marked as
> WITHOUT_ from the system, try running `make delete-old` in /usr/src.

Has the behaviour of make delete-old changed? As far as I can
remember, it doesn't remove stuff marked as WITHOUT_ --it's there to
deal with updates.

Chris

[Yuri Pankov]

ObsoleteFiles.inc also includes
tools/build/mk/OptionalObsoleteFiles.inc, which defines the file lists
for various WITH_|WITHOUT_ options.