| 1 |
Ben Munat schrieb: |
| 2 |
> Yikes... guess I gotta be careful with what I add to my .bashrc... added |
| 3 |
> this to root's .bashrc and locked myself out of my system! |
| 4 |
> |
| 5 |
> Before I exited (and then couldn't reconnect) I looked at ps -e and |
| 6 |
> there were hundreds of screen/bash processes... something went haywire. |
| 7 |
> |
| 8 |
> Managed to rm the .bashrc with ssh ... rm .bashrc but still had to |
| 9 |
> reboot to login... even restarting sshd (via webmin) didn't do the trick. |
| 10 |
> |
| 11 |
> So a warning to anyone who sees the previous message and tries it... do |
| 12 |
> it on a local machine first (I went straight for root on my remote |
| 13 |
> server... :-O) |
| 14 |
> |
| 15 |
|
| 16 |
Yes, you are absolutely right. Sorry, but instead I suggest using: |
| 17 |
|
| 18 |
[ $SHLVL -eq 1 ] && screen -A -m -d -S <screen name> /bin/bash |
| 19 |
|
| 20 |
But in general I wouldn't use root's bashrc to test such scripts. And I |
| 21 |
recommend keeping a separate ssh session running, so you remain able to |
| 22 |
remove faulty .bashrc's. Another thing which you should consider, at |
| 23 |
least for testing, is using ulimit. ("man ulimit") It gives you the |
| 24 |
possibility to limit the amount of processes a user can start. |
| 25 |
|
| 26 |
Just one word of explanation to the corrected line. At least in my |
| 27 |
system any bash instance invoked by screen gets a SHLVL greater than 1. |
| 28 |
Checking this env variable before running screen ensures that only your |
| 29 |
first root shell will start screen. |
| 30 |
To be honest I just forgot that *any* bash which is started, will |
| 31 |
evaluate .bashrc. |
Archives