'su lfs' dropping into the background

Bryan Kadzban bryan at kadzban.is-a-geek.net
Wed Jan 21 15:10:25 PST 2004


Alex Groenewoud wrote:
> root:~# useradd -s /bin/bash -m lfs -k /home/lfs
> 
> *snip*
> 
> root:~# useradd -s /bin/bash -m lfs -k /hmhmhm
> 
> *snip*
> 
> So I propose to add something like "-k /absent" or "-k /nosuch" to
> the useradd command in the book, together with a little explanation. 
> Anyone who sees any drawbacks?

Why not /dev/null, out of curiosity? (Anderson's post)  I think that
/dev/null makes it a very slight bit more obvious that nothing should
exist -- /dev/null is used in a lot of other contexts to mean "nothing"
or "nowhere".

MHO, of course.

> lfs:~$ bash --version | head -1
> GNU bash, version 2.04.0(1)-release (i386-suse-linux)
> 
> lfs:~$ env --version | head -1
> env (GNU sh-utils) 2.0
> 

I used the same env version when building my current LFS+NPTL system,
and didn't see this issue (I was coming from some ancient LFS -- I think
around v3.3 or so).

I can't remember ever using a bash that old, though, so that could be
it.  It didn't background (or whatever) with 2.05a.0(1)-release.

Actually, this may well be the problem (version of bash, that is).  From
the bash CHANGES file (the first part of
http://ftp.gnu.org/gnu/bash/bash-2.04-2.05.diff.gz):

<quote>
Fixed a bug that caused the shell process to end up in a different
process group than the controlling terminal if a job-control shell was
run with `exec' in the startup files.
</quote>

This was changed between bash 2.05-beta2 and 2.05-release (not 2.04 and
2.05-anything), and I'm also not sure about what being in a different
process group does (maybe it prevents wait() calls?).  But it looks like
it might be part of the issue, at least.



More information about the lfs-dev mailing list