I've got a strange problem. After I enter my password on a debian 6.0 system, I get the motd but then there is a 5-10 second pause until I get a shell prompt. If I press ctrl-c during that pause the prompt comes up instantly. What could be happening here? Am I killing the login process? Why might it be taking so long to invoke bash? I appreciate any suggestions.
Thanks
You can debug bash shell scripts using set -x and set +x. The set -x command enables debug mode and the set +x command disables it.
Putting set -x at the top of your $HOME/.bash_profile should cause debug information to be printed for your personal shell initialisation files. If as you say you get a 10 second delay you should be able to track it down quite easily. If This doesn't shed any light then go for the system wide initialisation file /etc/profile.
Bash Debugging and shell initialisation files
It's likely there's something in your .bashrc or .bash_profile. Or maybe some other startup file (/etc/profile et al).
Same problem as John Rix for me. /opt/vmware/bin/ovfenv was the culprit.
I found this post after doing the following investigation:
starting another bash would take up to 30 seconds on a CentOS6
strace bash
shows few lines before it hangs:
read(3, "LANG=`/opt/vmware/bin/ovfenv --q"..., 183) = 183
Removed the script from being executed with:
mv /etc/profile.d/zzzz-vamilocale.sh /etc/profile.d/zzzz-vamilocale.sh.ko
Related
I know there are many linux experts here, I wish to get little help with at command in Ubuntu.
I have been troubled by at command in ubuntu (18.04 and 20.04) for quite a while, but I don't know where I made a mistake. I've tried at on three of my Ubuntu systems and it doesn't work on any of them. at is very handle and nice job scheduler, I really want to get it to work so that I do not have to manually launch programs in the late night on a shared Ubuntu server. I read many tutorials on at command, here is a very good one.
at now + 1 minutes -f ~/myscript.sh, it looks really great and can save me lots of energy. Unfortunately, when myscript.sh is extremely simple,then at now + 1 minutes -f ~/myscript.sh can run smoothly and I get what I expected. Here is everything I have in myscript.sh:
echo $(date) > ~/Desktop/time.txt
On top of that, it never worked for me. For example when I change myscript.sh to
echo $(date) > ~/Desktop/time.txt
pycharm.sh
Basically what myscript.sh does it is noting down the time and to open Pycharm IDE. I can run sh myscript.sh without at , it wroks very well. However, when I run at at now + 1 minutes -f ~/myscript.sh, the time is noted down but Pycharm was not never opened (I can see the process in htop if Pycharm is open). Also at now + 1 minutes -f ~/script.sh does not work with any of my other shell scripts.
Could you please help me understand where I have done wrong and how to make it work. Thank you very much.
PyCharm and other GUI programs need a lot of information from your environment. The atd daemon which runs jobs for at does not have access to this environment. You will need to specify it directly.
I recommend running printenv redirected to a file in an at job. Then compare that to printenv running from a terminal in your GUI session. Find the differences and see if you can set them up the same way at the beginning of your at script.
I want to do the following thing: I want to replace the systemd program on my CentOS 7 installation, with a script, that will eventually start a shell where the user can input commands as root on the system console.
For this, I used the init=/sbin/myInit parameter. In this script I do some initialization, and in the end I call bash to enable the user to input commands. The interactive bash always appears on the screen.
Unfortunately, there is a problem with the input, that I haven't been able to solve: the input doesn't work correctly. When I press enter, only the second enter works, but no new line is performed on the screen. And when I type some characters, not all the characters are read. It seems like the console is in some Unicode mode (stty -a shows iutf8 parameter), and bash cannot correctly read the input. The output is fine, all the echo commands in my script are correctly printed on the screen (I only print ASCII characters).
I've tried all sorts of combinations, with different LC_ALL settings (LC_ALL=C, LC_ALL=C.utf-8, no LC_ALL or LANG variables initialization), redirect stdin/stdout/stderr to /dev/console, /dev/tty0 or /dev/tty1, the TERM variable is initialized to linux value, but nothing works. I tried unicode_start and unicode_stop commands, but unicode_stop doesn't work, and I get the error message "stty: standard input: unable to perform all requested operations". If I run showkey command, and I press the enter key, the correct keycode 28 is detected, same with normal boot.
Even stranger than this is the fact that if I'm using the init=/bin/bash kernel parameter, the input works fine, and if I manually run my script, it also works fine. If I copy the bash executable to something like /bin/mys, and I use init=/bin/mys, than same input problem occurs. It seems like the initrd image treats /bin/bash differently. Maybe it performs some initialization or something, that enables the bash to read correctly from the terminal. Why do we have this difference between init=/bin/bash and init=/bin/mys? It's the same executable in the end.
What am I doing wrong ?
As a general question about the init program, can somebody explain me what the init program should do to work correctly ? Any particular signals it has to respond to, any console initialization to be performed ?
I'm trying to solve this for days, and I cannot find any solution. On the web I couldn't find any article about this. So any suggestion would be greatly appreciated. Thank you.
I managed to pull a solution out for this one.
Turns out, at boot, the console is not initialized. I looked at the differences between the output of stty -a between the normal boot and the script boot (init=/sbin/myInit), and there are some differences between them: the console on normal boot had the following flags active on it: brkint ignpar ixon imaxbell isig icanon iexten echo, while when on script boot, those flags where cleared (stty reports them with - ). I'm not sure what they mean, except the echo flag, which I quickly noticed, because on each key press, no character ware printed on the screen.
So I decided to set those flags on my init script for /dev/console. After digging the stty manual page, I found the sane option, that sets the most important flags for normal console usage. So I added the line stty -F /dev/console sane in my init script.
But, there is a small problem. It seems that some console options cannot be changed by the stty command if the console is already opened by a process. So the first thing I did in my script is to redirect the stdin/stdout/stderr to /dev/null, via the line 0/dev/null, and then add the stty sane line, then redirect back the stdin/stdout/stderr to /dev/console.
I also noticed a process called plymouth, probably started by the CentOS initrd, so before the root was mounted and init script executed. I'm not sure if that process opened the system console, but I decided to eliminate it, by reconstructing a personalized initrd, by omitting the plymouth module from dracut (option -o plymouth).
After doing this, the script worked fine, and the bash process started by the script could read correctly the console.
Hope this helps somebody someday. Cheers
I am planning to run some bash scripts every minute, and I wrote:
* * * * * bash ~/Dropbox/temp_scripts/run_all_scripts
in crontab.
It was supposed to run every minute, but it did not work. Does anyone have idea why this happens?
Transferring a comment into an answer.
Add I/O redirection to the command line in the crontab entry:
>/tmp/run_all_scripts.out 2>/tmp/run_all_scripts.err
Review the contents of the files after a minute or two has passed. Consider recording the environment to see if that's part of the problem. And consider using bash -x instead of just bash.
If you still don't get anything (the files in /tmp are not created), then you've got issues with cron; the daemon isn't running, or your user does not have permission to use it (but crontab isn't telling you that), or you've not submitted your crontab to the program (what does crontab -l say?), or … whatever is really wrong.
Note, too, that the output from cron jobs is normally (well, at least sometimes — on Mac OS X for a system I currently use, and Solaris for another that I've used previously) emailed to the person whose job it is. You should review the email on the system.
Thank you! I have already fixed it! The reason why it does not work is I used "ls -a .sh" in the script, and when the crontab did not find any *.sh files in the folder it was executing. When modifying it to "ls -a $HOME/Dropbox/temp_scripts/.sh", everything works! This debugging technique is quite helpful!
It is, in many ways, the most basic of debugging techniques — make sure you see what is actually happening. If you're not sure why a shell script isn't working, make sure you can see that it is executing and what it is producing in the way of output, and (very often) make sure you can see what it is executing with bash -x or equivalent. (AFAIK, all shells support -x to trace the execution.)
I am trying to schedule the execution of a shell-script with the Linux tool "at".
The shell script (video.sh) looks like this:
#!/bin/sh
/usr/bin/vlc /home/x/video.mkv
The "at" command:
at -f /home/x/video.sh -t 201411052225
When the time arrives, nothing happens.
I can execute the shell-script just fine via console or by rightclicking - Execute. VLC starts like it is supposed to. If I change the script to e.g. something simple like
#!/bin/sh
touch something.txt
it works just fine.
Any ideas, why "at" will not properly execute a script that starts a graphical program? How can I make it work?
You're trying to run an X command (a graphical program) at a scheduled time. This will be extremely difficult, and quite fragile, because the script won't have access to the X server.
At the very least, you will need to set DISPLAY to the right value, but even then, I suspect you will have issues with authorisation to use the X screen.
Try setting it to :0.0 and see if that works. But if you're logged out, or the screensaver's on, or any number of other things...
(Also, redirect vlc's stdout and stderr to a file so that you can see what went wrong.)
Your best bet might be to try something like xuserrun.
I suspect that atd is not running. You have to start the atd daemon before (and to set DISPLAY variable like chiastic-security said) ;)
You can test if atd is running with
pidof atd &>/dev/null && echo 'ATD started' || echo >&2 'ATD not started
Your vlc command should be :
DISPLAY=:0 /usr/bin/vlc /home/x/video.mkv
(Default display)
I'm having some problems working with my development environment. Specifically, after I invoke the screen utility from within Cygwin I lose the ability to do tab completion. Before I invoke screen however tab completion works just fine.
I messed around with setting different values for the TERM env variable (VT100, xterm etc) but without success. It must be something trivial but I have no idea anymore. Does StackOverflow have any suggestions for me?
when you issue 'screen' from inside cygwin it might put you in another shell like /bin/sh instead of /bin/bash (and bash is where you're getting the tab completion from).
To fix the problem you could edit your .screenrc file (found in your home directory) and add in this line:
shell bash
Then try running screen again and you should see tab completion work within this new window.
The problem is that bash needs to be run as a login shell in order to have tab completion in the default cygwin setup. If you run bash in a cygwin bash you won’t have tab completion either. To set screen to run bash in login mode, add this line to your ~/.screenrc file:
shell -bash
I had a similar problem with git autocompletion not working when using screen on a linux machine, but wasn't due to a different shell. I fixed it using this question: Git autocomplete in screen on mac os and doing the following:
Get the git autocompletion script
curl https://raw.github.com/git/git/master/contrib/completion/git-completion.bash -OL
why would you want that hanging around?
mv git-completion.bash .git-completion.bash
add this line to your ./bashrc
source ~/.git-completion.bash
Then in your terminal
source ~/.bashrc
That worked for me.
(I imagine after three years you've probably solved your problem, but I hope this helps someone else)