what does "-bash: fg: no job control" on login mean?

[Bosse_B]

I have an RPi4B box with the latest Raspbian Buster and I access it both via VNC for development and SSH (PuTTY) for management.
Now when I log in I see this at the end of the greeting message:

Code: Select all

Last login: Thu Dec 26 10:25:55 2019 from 192.168.119.166
-bash: fg: no job control

Never seen it before. What does it mean????

[fbe]

A command, beginning with "%" in /etc/profile, /etc/profile.d/*.sh or ~/.profile?

[Paeryn]

Also possible that you have used a formatting string that you have tried to quote with backticks e.g.

Code: Select all

date +`%d`

If you quote a string with backticks then the shell will try to execute the string and use its output in place of the string. The command %d will try to run fg %d which says to bring the background job d into the foreground.

[Bosse_B]

How can I find out what it is?

There is no % or ` inside /etc/profile or ~/.profile

These are the files I found in /etc/profile.d:

Code: Select all

 $ ls -l /etc/profile.d/
total 20
-rw-r--r-- 1 root root   95 Apr 29  2019 at-dbus-fix.sh
-rw-r--r-- 1 root root  664 Mar  1  2019 bash_completion.sh
-rw-r--r-- 1 root root  324 May  9  2019 sshpwd.sh
-rw-r--r-- 1 root root 1945 Dec 28  2018 vte-2.91.sh
-rw-r--r-- 1 root root  450 Jul 22 11:22 wifi-check.sh

The content of /etc/profile is:

Code: Select all

# /etc/profile: system-wide .profile file for the Bourne shell (sh(1))
# and Bourne compatible shells (bash(1), ksh(1), ash(1), ...).

if [ "`id -u`" -eq 0 ]; then
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games"
fi
export PATH

if [ "${PS1-}" ]; then
  if [ "${BASH-}" ] && [ "$BASH" != "/bin/sh" ]; then
    # The file bash.bashrc already sets the default PS1.
    # PS1='\h:\w\$ '
    if [ -f /etc/bash.bashrc ]; then
      . /etc/bash.bashrc
    fi
  else
    if [ "`id -u`" -eq 0 ]; then
      PS1='# '
    else
      PS1='$ '
    fi
  fi
fi

if [ -d /etc/profile.d ]; then
  for i in /etc/profile.d/*.sh; do
    if [ -r $i ]; then
      . $i
    fi
  done
  unset i
fi

I have not edited this file ever as far as I can remember...

And why did it happen now, it was not like this for the 6 months I have used this RPi....
Last time I logged in on Dec 26 everything was OK.

[Bosse_B]

No-one really knows, right?
It is very irritating every time I log on via PuTTY.
It also happens whenever I open a new terminal window in the Raspbian GUI.

How can I get rid of this strange message?????

[GlowInTheDark]

First, a couple of bits of meta-question:
1) Is it causing you any actual reduction in utility? This is not meant to minimize the importance of it, but it helps to contextualize whether this is just a "That's weird; why is it doing this?" vs. "This is stopping me from getting work done".

2) Could you provide a screenshot? I know you've described it pretty well, but it is likely that somebody else might be able to spot it better if given an actual "look over your shoulder".

Next, it sounds to me like this is coming from one of the bash startup files. Did you modify (or did you install any software that might have modified) any of the private bash startup files (.profile, .bashrc, .bash_profile) or the public ones (/etc/profile and the contents of /etc/profile.d)

Finally, you will need to debug this. I.e., start putting "echo" statements in the various startup files and see where the message is coming from.

BTW, the bit about "no job control" usually comes from running a shell with its stdin redirected to a non-terminal device (e.g., a file). So, you might want to be thinking along those lines, as to how that might have happened.

[dickon]

Sticking

Code: Select all

set -x

somewhere at the top of the usual login scripts -- .login, .bashrc, .bash_login etc. -- might be useful.

[ejolson]

Sticking

Code: Select all

set -x

somewhere at the top of the usual login scripts -- .login, .bashrc, .bash_login etc. -- might be useful.

I've seen it before and it was definitely because something was broken, but I can't remember what. Maybe something like the /tmp filesystem being full or the wrong permissions in some part of the home directory or maybe related to the allocation of pty devices. I do remember that it took more than an hour one evening to fix, because it was not clear what was causing the problem. I would try a forced reinstall of ssh to begin with.

[Bosse_B]

Thanks for your suggestions!

First, a couple of bits of meta-question:
1) Is it causing you any actual reduction in utility? This is not meant to minimize the importance of it, but it helps to contextualize whether this is just a "That's weird; why is it doing this?" vs. "This is stopping me from getting work done".

Since it suddenly appeared out of the blue I am worried that there is some underlying problem that might cause damage.
The terminal itself seems to work as before though. I am not stopped for doing my work as far as I have tested yet.

2) Could you provide a screenshot? I know you've described it pretty well, but it is likely that somebody else might be able to spot it better if given an actual "look over your shoulder".

This is how a terminal window on Raspbian Buster looks like when opened from the button at the top.The same message is displayed in PuTTY when I connect with SSH right above the cursor line. But in the PuTTY session there are also a number of lines above that, which deal with the state of the system.

RPiTerminalStart.png (10.37 KiB) Viewed 1063 times

Next, it sounds to me like this is coming from one of the bash startup files. Did you modify (or did you install any software that might have modified) any of the private bash startup files (.profile, .bashrc, .bash_profile) or the public ones (/etc/profile and the contents of /etc/profile.d)

As far as I can remember I did not, I had been using the VNC connection for a while from my Win 7 laptop while developing code on the RPi.
But what happened during the first part of December is that I got a new Win 10 laptop and I was busy installing all of the tools and tweaks on that. Took a long time since I have a *lot* of tools and software on that. This included installing VNC on the Win10 laptop and adjusting the start file for the VNC virtual desktop on the RPi.

Finally, you will need to debug this. I.e., start putting "echo" statements in the various startup files and see where the message is coming from.

How can that be done? Where should I put the echo statements? Do you mean on top of each of the mentioned files and see which echoed id comes before and which after the offending line?

BTW, the bit about "no job control" usually comes from running a shell with its stdin redirected to a non-terminal device (e.g., a file). So, you might want to be thinking along those lines, as to how that might have happened.

Unfortunately I am not really very used to Linux that I know which files are in fact executed on start of a terminal session....
However, I added an echo line on top of each of the files you mentioned above and the result when logging in via PuTTY is (after I also added a finish echo into .bashrc):

Code: Select all

Last login: Mon Jan 20 00:19:25 2020 from 192.168.119.166
From /etc/profile/
From /etc/profile.d/bash_completion.sh
From /etc/profile.d/vte-2.91.sh
From /etc/profile.d/wifi-check.sh
From .profile
From .bashrc
-bash: fg: no job control
Leaving .bashrc
pi@rpi4-gui:~ $

So there seems to be something inside ~/.bashrc that causes the output....
Now it is too late in the night to continue troubleshooting, I will resume tomorrow.

EDIT:
Well I could not sleep without trying a bit more with echo inside .bashrc...
So I have narrowed down where the actual source of the problem is:
At the bottom of .bashrc I have entered a formatting config to be used with the history command:

Code: Select all

echo ".bashrc at: 13"
( %F = yyyy-mm-dd  %T = hh:mm:ss)
echo "At: 14"
# Add timestamp to history lines
export HISTTIMEFORMAT="%F %T "

echo "Leaving .bashrc"

This causes the following output when I log on:

Code: Select all

Last login: Mon Jan 20 00:48:25 2020 from 192.168.119.166
.bashrc at: 13
-bash: fg: no job control
At: 14
Leaving .bashrc
pi@rpi4-gui:~ $

So it seems like this line is causing the problem, why?:

Code: Select all

( %F = yyyy-mm-dd  %T = hh:mm:ss)

[Paeryn]

So I have narrowed down where the actual source of the problem is:
At the bottom of .bashrc I have entered a formatting config to be used with the history command:

Code: Select all

echo ".bashrc at: 13"
( %F = yyyy-mm-dd  %T = hh:mm:ss)
echo "At: 14"
# Add timestamp to history lines
export HISTTIMEFORMAT="%F %T "

echo "Leaving .bashrc"

This causes the following output when I log on:

Code: Select all

Last login: Mon Jan 20 00:48:25 2020 from 192.168.119.166
.bashrc at: 13
-bash: fg: no job control
At: 14
Leaving .bashrc
pi@rpi4-gui:~ $

So it seems like this line is causing the problem, why?:

Code: Select all

( %F = yyyy-mm-dd  %T = hh:mm:ss)

The line that starts with ( %F is what is causing bash to warn about no job control. Bash is starting a new sub-shell (the opening bracket) and the first instruction is %F which says look for a background job that starts with a capital F and bring it to the foreground. Since there is no such background process to match it to, it bails out. I assume that line is a continuation of a previous line but has somehow been separated to make it a line all on its own.

[GlowInTheDark]

Yeah, something like: %F = yy-mm-dd

doesn't make any real sense. Where did you get the idea for that?

[PeterO]

I think you want something like

Code: Select all

export HISTTIMEFORMAT="%F %T "

It looks like you copy/pasted the explanation of %F and %T rather than the command that used them

See https://www.cyberciti.biz/faq/unix-linu ... date-time/
PeterO

PS: Now I see that the export line IS there and Hippy's analysis is right.
PeterO

[hippy]

So it seems like this line is causing the problem, why?:

Code: Select all

( %F = yyyy-mm-dd  %T = hh:mm:ss)

I would also guess you inadvertently copy-and-pasted some of a preceding comment when bringing in the 'export' line into your file. It was probably something like below in the original -

Code: Select all

# Set the time ( %F = yyyy-mm-dd  %T = hh:mm:ss)
export HISTTIMEFORMAT="%F %T "

[Bosse_B]

Might be a copy-paste problem that happened, but I will never know...
Anyway removing the line made the offending output go away.

It all happened when I was resurrecting my setup after I had made WiFi on my RPi4 no longer work a couple of months back.
So I used history by dumping its output to a file and then I started over with a fresh SD-card and created a new system.
I mounted the old SD card via a USB carrier on the new system so I had access to the old system while building the new.
This way I could grep for all apt installs I had done and repeat them on the new system and copy over my data in home/pi etc.

But that is when I noted that the history output was really lacking in that there was no timestamp on its lines...
So I googled for help on that and found this page where I could set it all up. However, the timestamp display was less than friendly using the settings in that post so I Googled on and finally found the format I use. This worked fine and I did not get the logon message at the time.
I must have done something I can no longer remember to get that strange line into .bashrc...

The current setup is like this:

Code: Select all

# don't put duplicate lines or lines starting with space in the history.
HISTCONTROL=ignoreboth
# append to the history file, don't overwrite it
shopt -s histappend
# for setting history length see HISTSIZE and HISTFILESIZE in bash(1)
HISTSIZE=15000
HISTFILESIZE=20000
# Add timestamp to history lines
export HISTTIMEFORMAT="%F %T "
#Save command to history immediately instead of at session end
PROMPT_COMMAND='history -a'

I have observed that history does not transfer between session windows, so if I have several PuTTY sessions open or several Terminal windows in the desktop these seem to remember only the commands executed by the respective sessions...
I sometimes have long running tasks, like building a development IDE, and then I open a second or third session and enter new commands there. These are not visible in the other session's history even though I think they use the same history file...

I hoped that the last line above would fix this (found it only yesterday), but it does not...
Any ideas of how to get the correct history when using several terminal sessions as the same user?

PS: I now read the page https://www.cyberciti.biz/faq/unix-linu ... date-time/ and saw the format he suggested with day-month-year..
This sems to be a bad idea if you want to have any consistency in sorting by date. The sort order should be y-m-d rather than the opposite...
DS

[dickon]

A quick perusal of the man page suggests that

Code: Select all

PROMPT_COMMAND='history -a; history -n'

ought to do it. I haven't tried it myself.

Next time you need to reinstall, have a look at

Code: Select all

(cd /mnt/oldroot && dpkg --get-selections) | dpkg --set-selections
apt-get dselect-upgrade

as this gets you all the packages you've previously installed, and removes any you removed.

[Bosse_B]

Next time you need to reinstall, have a look at

Code: Select all

(cd /mnt/oldroot && dpkg --get-selections) | dpkg --set-selections
apt-get dselect-upgrade

as this gets you all the packages you've previously installed, and removes any you removed.

QUESTIONS:
1) In your command you use ( ) to enclose the first part, is this needed or is it done to indicate replacement of the actual locations?
2) If the cause of the system failure was actually installing (via apt) some package, how can I view the list of packages so I can edit it?

In my case I was trying to make WiFi create an access point for a tablet to connect to in order to access the RPi website, but not out onto the Internet. After some tests using googled howto:s my Pi would not revert to a stable state concerning WiFi. So I had to rebuild it.
Based on this I would like to know what was installed up to but not including the experimental installs.

Can I just do this (and again, what about the parentheses?):

Code: Select all

(cd /mnt/oldroot && dpkg --get-selections) > oldinstalledsoftware.txt
#edit oldinstalledsoftware.txt and remove the offending entries
dpkg --set-selections < oldinstalledsoftware.txt
apt-get dselect-upgrade

I hope that dpkg --get-selections produces a time sorted list....

[dickon]

QUESTIONS:
1) In your command you use ( ) to enclose the first part, is this needed or is it done to indicate replacement of the actual locations?

Brackets just make the command(s) run in a sub-shell. This means that the 'cd' command won't have any impact outside of them.

What's worse, of course, is that I meant 'chroot', not 'cd':

Code: Select all

(chroot /mnt/oldroot && dpkg --get-selections) | dpkg --set-selections

2) If the cause of the system failure was actually installing (via apt) some package, how can I view the list of packages so I can edit it?

In my case I was trying to make WiFi create an access point for a tablet to connect to in order to access the RPi website, but not out onto the Internet. After some tests using googled howto:s my Pi would not revert to a stable state concerning WiFi. So I had to rebuild it.
Based on this I would like to know what was installed up to but not including the experimental installs.

Can I just do this (and again, what about the parentheses?):

Code: Select all

(cd /mnt/oldroot && dpkg --get-selections) > oldinstalledsoftware.txt
#edit oldinstalledsoftware.txt and remove the offending entries
dpkg --set-selections < oldinstalledsoftware.txt
apt-get dselect-upgrade

Yes, but again: chroot, sorry. I clearly wasn't paying enough attention.

I hope that dpkg --get-selections produces a time sorted list....

Alphabetical, I'm afraid.

[Bosse_B]

So I still need history to weed out what was installed at the experimentation time...

[GlowInTheDark]

Time to start a new thread.

Call it:

Recovering from a Pi SD card crash

or

How to install all the packages to my new system that were installed on my old system

I'm actually serious, because this is a frequently endured problem and it would be good for there to be a good write-up on how to do this sort of thing. Burying it in an un-related thread makes it hard to find.