1 |
On Mon, Oct 14, 2013 at 4:03 PM, David Leverton |
2 |
<levertond@××××××××××.com> wrote: |
3 |
> So to work around that limitation we insist that everyone change how their |
4 |
> systems are set up, and still have to reintroduce mtab under a different |
5 |
> name ("utab", hidden away under /run) because /proc/self/mounts *doesn't* |
6 |
> contain everything that's supposed to be in mtab after all? |
7 |
|
8 |
The whole design of /etc/mtab is broken. It isn't a list of |
9 |
everything that is mounted - it is a list of everything done by the |
10 |
mount command (the command - not the system call). The handbook even |
11 |
has a line about having to manually populate it before running grub |
12 |
since it is flat-out wrong when you're in a chroot. There are lots of |
13 |
things that can cause it to get out-of-sync. |
14 |
|
15 |
Perhaps there are edge cases where the symlink isn't sufficient - |
16 |
that's what this thread is all about. However, I've never liked the |
17 |
design of mtab. It isn't surprising to me that distros are largely |
18 |
ditching it. |
19 |
|
20 |
> /etc/resolv.conf |
21 |
|
22 |
As Mike already pointed out, resolution is actually a userspace |
23 |
function entirely (I'm not sure if I were designing things from |
24 |
scratch that I'd put it in the C library, but...). |
25 |
|
26 |
However, if you want to know the hostname, you should be calling uname |
27 |
and not looking around for /etc/hostname or whatever. The kernel will |
28 |
tell you the truth as it applies to your process, not what you think |
29 |
should be the truth based on what amounts to a logfile. |
30 |
|
31 |
Rich |