Re: bash using unknown tmp - library based? static link on linux? (was Re: bash not using pipes or /tmp @ boot?)

[Linda Walsh]

Chet Ramey wrote:
> On 10/8/14, 1:17 AM, Linda Walsh wrote:
> > P_tmpdir?  in ENV?
>
> No.  P_tmpdir is a #define in stdio.h that holds the full pathname of the
> compilation environment's preferred temporary directory.
>
> > I don't have TMP or TMPDIR in my env during normal runtime
> > and tmp's were put in /tmp... 
>
> Then P_tmpdir is probaby "/tmp".
>
> > I don't know where they were going
> > @ boot time, as /tmp and /var/tmp were writeable, but still
> > TMP/TMPDIR were unset.  
>
> Did you verify $TMPDIR?
---
        As mentioned above, I verified that that TMP,TMPDIR were both unset.
> Since the thing that differs is $TMPDIR, presumably its value when
> executing in the boot-time environment, you might want to start with
> looking at that.
---
        It is empty or null:
> > /etc/init.d/boot.assign_netif_names#212(read_actuals)> echo 'TMP=, TMPDIR='
TMP=, TMPDIR=

My "runtime" (same as boot time) /bin/bash shows linking only against
rootfs files:

  linux-vdso.so.1 (0x00007fffecb96000)
  libreadline.so.6 => /lib64/libreadline.so.6 (0x0000003033c00000)
  libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007f8e7fb41000)
  libdl.so.2 => /lib64/libdl.so.2 (0x0000003002800000)
  libc.so.6 => /lib64/libc.so.6 (0x0000003002000000)
  /lib64/ld-linux-x86-64.so.2 (0x0000003000000000)

So I'm doubting the library... but the process-substitution works now,
which is what I started with -- I'm thinking this script ran earlier, before
(the order has changed, putting most files in step 50 now), but
udev runs (and likely finishes) much earlier than before.


the original suse boot sequence used "tmpfs" and let
udev populate it from there, vs. I mount 'devtmpfs' which
already has an entry for /dev/fd.

I remember moving changing /dev's initial mount type to "devtmpfs"
from "tmpfs" under the reasoning that it was better to
have some funcionality than none.
But suse does all their /dev init on an empty "tmpfs" from
their ram disk.  They likely feel (or felt) safe in letting
udev do all the initialization, as they can wait until it is
done before doing their kexec or pivot to the hard-disk root.


That's another diff tween my sys and suse's.
I boot from HD, w/o an initdisk), so I need to ensure the
disk image supports booting directly (thus devtmpfs instead
of tmpfs).  That makes for a good reason for the differences I saw, since any
interactive pausing on my part would allow udev to complete its basic
setup and thus /dev/fd would have pointed correctly to /proc/self/fd.
I.e. if the bash-script needing /dev/fd ran too early, udev wouldn't have
finished populating /dev on an empty tmpfs.

Only way to boot faster now would be a special mount script to
allow parallel mounts by dependencies (current mount's parallel
option isn't smart enough to mount by deps), since out of a 33s
boot, 18s are taken by localfs mount in "mount -v -a"


I guess what I would like is a more robust proc-subst -- so if /dev/fd
wasn't there, then bash would fall back to pipes and emulate the same
functionality (trap open of /dev/fd/63 in child, and redirect it directly to
parent pipe) -- that's what I mean by circumventing the stdlibc and doing
that bit (interception) on your own.

That's also what I mean by "voodoo feature" referring to proc-subst.
It's a feature that's not really there until it is -- but a script writer
really should be careful about using it in portable code as it may be
there or may not.  Sorta like Reagan's voodoo economics -- spend more money
to help the economy -- but he spent money that wasn't really there... he
just created an additional 2T debt to fund his high-on-the-hog presidency...

So it's not that voodoo might not work in some situations -- just that you
probably can't or shouldn't rely on it, "portably" given its current
fallback behavior when it can't find /dev/fd (you might get
zombie processes or ...)  :-O