I'm accustomed have longer bash history - usually my HISTSIZE=10000. Never from Redhat 4 epoch was problems with this, but now at F15 and F16 I in several cases I found weirdness, when my commands are missing in history, in one case I had .bash_history completely empty.
IMO it is problem in newer bash versions, but yet more I suspect when it may be any cripled systemd behavior at init 0/6 (sorry, i want say poweroff.target/reboot.target ;), whether systemd (in order to halt/reboot computer several microseconds faster) kill bash before it is able save their stuff.
Have You met someone with this problem? Any idea how diagnose it?
Thanks, Franta
On Sat, Mar 24, 2012 at 10:46, Frantisek Hanzlik franta@hanzlici.cz wrote:
IMO it is problem in newer bash versions, but yet more I suspect when it may be any cripled systemd behavior at init 0/6 (sorry, i want say poweroff.target/reboot.target ;), whether systemd (in order to halt/reboot computer several microseconds faster) kill bash before it is able save their stuff.
This is just a ridiculous claim. Do you have any evidence to support this claim?
suvayu ali wrote:
On Sat, Mar 24, 2012 at 10:46, Frantisek Hanzlik franta@hanzlici.cz wrote:
IMO it is problem in newer bash versions, but yet more I suspect when it may be any cripled systemd behavior at init 0/6 (sorry, i want say poweroff.target/reboot.target ;), whether systemd (in order to halt/reboot computer several microseconds faster) kill bash before it is able save their stuff.
This is just a ridiculous claim. Do you have any evidence to support this claim?
I haven't, therefore I ask there when somebody have same problem, and how I should diagnose this issue. I not know, how reproduce it, it seems occur pure randomly and rarely - but I'm sure it occur at least in 8-10 cases at several different F15/F16 i686 machines.
Why You think this claim is ridiculous? - it may be bash bug, why not? In F15/16 is new 4.2 line, maybe it introduce some different way with history treating, is insafe when several bash instance for same user ends simultaneously, etc.
- why it could not be systemd bug? When is servicing 0/6 runlevels in similar way as SYSV init/upstart before, then send SIGTERM and then SIGKILL to processes - and when it kill bash before is able write history, then what?
- one another reason tackled me. I very often use Midnight Commander (mc), which probably run another bash process as its child. Then perhaps problem may occur when at exiting mc it kill child bash before bash write its history.
I have no idea for other reasons to this problem. What seems You ridiculous here?
suvayu ali wrote:
On Sat, Mar 24, 2012 at 10:46, Frantisek Hanzlik franta@hanzlici.cz wrote:
IMO it is problem in newer bash versions, but yet more I suspect when it may be any cripled systemd behavior at init 0/6 (sorry, i want say poweroff.target/reboot.target ;), whether systemd (in order to halt/reboot computer several microseconds faster) kill bash before it is able save their stuff.
This is just a ridiculous claim. Do you have any evidence to support this claim?
And more - at several important machines when I want reboot them, I press for logging off and then login on for this only "shutdown -r now" command. And by then I at these machines not observed problems with bash history. Maybe it is speculation, but seem for me as systemd causation.
Franta
On Sat, Mar 24, 2012 at 12:39, Frantisek Hanzlik franta@hanzlici.cz wrote:
suvayu ali wrote:
On Sat, Mar 24, 2012 at 10:46, Frantisek Hanzlik franta@hanzlici.cz wrote:
IMO it is problem in newer bash versions, but yet more I suspect when it may be any cripled systemd behavior at init 0/6 (sorry, i want say poweroff.target/reboot.target ;), whether systemd (in order to halt/reboot computer several microseconds faster) kill bash before it is able save their stuff.
This is just a ridiculous claim. Do you have any evidence to support this claim?
And more - at several important machines when I want reboot them, I press for logging off and then login on for this only "shutdown -r now" command. And by then I at these machines not observed problems with bash history. Maybe it is speculation, but seem for me as systemd causation.
I have used shutdown many times since Fedora switched to systemd. It has always worked for me. I think your problem is more likely due to some options or commands in your bashrc and profile files. If you really believe another program is to blame, I would rather investigate programs which interact with your desktop session more closely (e.g. your terminal emulator, your desktop's session manager, some faulty cron job, a bug in some script, ... I can keep going), rather than point fingers at systemd.
If I were you, I would check some of the following:
1. Do you use any kind of history manipulation commands in your rc or profile files (e.g. any commands like `history <options>`)? 2. Do you have any history related environment variable set to some undefined value (could be a typo, a change in compatibility between versions, or some other reason)? 3. Do you have anything in your prompt related variables that could be misbehaving (e.g. PS1, PROMPT_COMMAND, etc)? 4. Do you have some stray old rc file messing up the settings? 5. Could there be some rc files from some other compatible shell interfering with your bash instance?
When the problem occurs again, I would also check for the last modification time and size of your history file to confirm the observation.
Franta
Hope the pointers above help.
suvayu ali wrote:
On Sat, Mar 24, 2012 at 12:39, Frantisek Hanzlik franta@hanzlici.cz wrote:
suvayu ali wrote:
On Sat, Mar 24, 2012 at 10:46, Frantisek Hanzlik franta@hanzlici.cz wrote:
IMO it is problem in newer bash versions, but yet more I suspect when it may be any cripled systemd behavior at init 0/6 (sorry, i want say poweroff.target/reboot.target ;), whether systemd (in order to halt/reboot computer several microseconds faster) kill bash before it is able save their stuff.
This is just a ridiculous claim. Do you have any evidence to support this claim?
And more - at several important machines when I want reboot them, I press for logging off and then login on for this only "shutdown -r now" command. And by then I at these machines not observed problems with bash history. Maybe it is speculation, but seem for me as systemd causation.
I have used shutdown many times since Fedora switched to systemd. It has always worked for me. I think your problem is more likely due to some options or commands in your bashrc and profile files. If you really believe another program is to blame, I would rather investigate programs which interact with your desktop session more closely (e.g. your terminal emulator, your desktop's session manager, some faulty cron job, a bug in some script, ... I can keep going), rather than point fingers at systemd.
If I were you, I would check some of the following:
- Do you use any kind of history manipulation commands in your rc or profile files (e.g. any commands like `history <options>`)?
- Do you have any history related environment variable set to some undefined value (could be a typo, a change in compatibility between versions, or some other reason)?
- Do you have anything in your prompt related variables that could be misbehaving (e.g. PS1, PROMPT_COMMAND, etc)?
- Do you have some stray old rc file messing up the settings?
- Could there be some rc files from some other compatible shell interfering with your bash instance?
When the problem occurs again, I would also check for the last modification time and size of your history file to confirm the observation.
Franta
Hope the pointers above help.
Hmm, I'm only not systemd fanatical sectarian. It is program as others, new thing, with bugs, is evolving according to system/distributions needs. IMO tell something as described here: http://0pointer.de/blog/projects/why.html without single false point to systemd, it simply isn't true.
Regarding Your recommendations - I personally think problem isn't there (with F15 I switched to Xfce, but desktop manager probably isn't culprit as at some machines where problem occurs I'm working only in console. System and user profile/bashrc are Fedora's original (only difference is "HISTORY=10000" in /etc/profile, and several aliases in root's .bashrc (for rpm, I use these for years), nothing else. Points 1)-5) too aren't probable/possible - they not exist or their resulst would be more predictable.
Now occurred to me that i can watch several (mainly roots) history files by incrond and start some script which log some events on it. Maybe it helps. Thanks.
Frantisek Hanzlik wrote:
And more - at several important machines when I want reboot them, I press for logging off and then login on for this only "shutdown -r now" command. And by then I at these machines not observed problems with bash history. Maybe it is speculation, but seem for me as systemd causation.
I have noticed that when I shut a computer down using the command line, systemd will kill any open bash sessions before they get a chance to save the history to ~/.bash_history.
If this seriously bothers you, you could investigate the history command, and possibly put it into the PROMPT_COMMAND environment variable so the history is written to disk each time the shell shows a new prompt.
Hope this helps,
James.
On Sat, 24 Mar 2012 10:46:01 +0100 Frantisek Hanzlik franta@hanzlici.cz wrote:
I'm accustomed have longer bash history - usually my HISTSIZE=10000. Never from Redhat 4 epoch was problems with this, but now at F15 and F16 I in several cases I found weirdness, when my commands are missing in history, in one case I had .bash_history completely empty.
IMO it is problem in newer bash versions, but yet more I suspect when it may be any cripled systemd behavior at init 0/6 (sorry, i want say poweroff.target/reboot.target ;), whether systemd (in order to halt/reboot computer several microseconds faster) kill bash before it is able save their stuff.
Have You met someone with this problem?
I suspect I have. I remember rebooting after a complicated command here in F15, and when I restarted I wanted to bring it back out of history, and it wasn't there. I thought I was just misremembering. I've started closing terms with history -a; exit before shutdown to avoid the problem. I also use mc and screen - haven't really been monitoring them for this behavior. Also, like you, I have history set really high, 100,000. Maybe it is the size causing problems?
While this isn't proof, it does add support for your observation. And now that you've mentioned it, I'll keep an eye out. I have rules about commands not to add to history (ls, cd, etc.). And not to add duplicate commands, though this is only duplicates of the last command, not all of history. Perhaps there has been a change in their behavior.
Any idea how diagnose it?
Maybe a test would be to use a unique command (not already in history) at a term, and then shut down, and see if it is in history on reboot. I just rebooted after upgrading the kernel. Next upgrade I'll do this, if I remember.
Hi Frantisek,
On Sat, Mar 24, 2012 at 15:15, Frantisek Hanzlik franta@hanzlici.cz wrote:
Now occurred to me that i can watch several (mainly roots) history files by incrond and start some script which log some events on it. Maybe it helps.
I recalled your post and did a check before I rebooted my laptop today (after 7 days). I think you were correct and my claim that its a ridiculous idea was wrong.
This is what I did:
1. I closed all running apps except for a terminal. 2. Executed these commands $ echo "1 test" $ echo "2 test" $ echo "3 test" $ sudo shutdown -P now 3. On turning on the laptop again, I could not find either of the three commands with history | grep -E "echo.+test"
In addition to $HISTFILE, I log all my history to a separate file. That file _did_ have all the test and the shutdown commands. So we can conclude bash was doing the right thing and systemctl is to blame.
At the moment I am very busy, so I would urge you to file a bug report. If you post the bug id back to the list, I'll try to add more comments if I find anything with regards to this.
Thanks,
On 03/27/2012 04:43 AM, suvayu ali wrote:
Hi Frantisek,
On Sat, Mar 24, 2012 at 15:15, Frantisek Hanzlik franta@hanzlici.cz wrote:
Now occurred to me that i can watch several (mainly roots) history files by incrond and start some script which log some events on it. Maybe it helps.
I recalled your post and did a check before I rebooted my laptop today (after 7 days). I think you were correct and my claim that its a ridiculous idea was wrong.
This is what I did:
- I closed all running apps except for a terminal.
- Executed these commands $ echo "1 test" $ echo "2 test" $ echo "3 test" $ sudo shutdown -P now
- On turning on the laptop again, I could not find either of the three commands with history | grep -E "echo.+test"
In addition to $HISTFILE, I log all my history to a separate file. That file _did_ have all the test and the shutdown commands. So we can conclude bash was doing the right thing and systemctl is to blame.
At the moment I am very busy, so I would urge you to file a bug report. If you post the bug id back to the list, I'll try to add more comments if I find anything with regards to this.
FWIW, I did the same test on a VM running F16. After restarting, this was the last thing in my .bash_history file....
echo "4 Test" ; sudo shutdown -P now
So, it isn't clear to me that it is a consistent problem. Maybe a race condition?
Hi Ed,
On Tue, Mar 27, 2012 at 04:27, Ed Greshko Ed.Greshko@greshko.com wrote:
On 03/27/2012 04:43 AM, suvayu ali wrote:
Hi Frantisek,
On Sat, Mar 24, 2012 at 15:15, Frantisek Hanzlik franta@hanzlici.cz wrote:
Now occurred to me that i can watch several (mainly roots) history files by incrond and start some script which log some events on it. Maybe it helps.
I recalled your post and did a check before I rebooted my laptop today (after 7 days). I think you were correct and my claim that its a ridiculous idea was wrong.
This is what I did:
- I closed all running apps except for a terminal.
- Executed these commands
$ echo "1 test" $ echo "2 test" $ echo "3 test" $ sudo shutdown -P now 3. On turning on the laptop again, I could not find either of the three commands with history | grep -E "echo.+test"
In addition to $HISTFILE, I log all my history to a separate file. That file _did_ have all the test and the shutdown commands. So we can conclude bash was doing the right thing and systemctl is to blame.
At the moment I am very busy, so I would urge you to file a bug report. If you post the bug id back to the list, I'll try to add more comments if I find anything with regards to this.
FWIW, I did the same test on a VM running F16. After restarting, this was the last thing in my .bash_history file....
echo "4 Test" ; sudo shutdown -P now
So, it isn't clear to me that it is a consistent problem. Maybe a race condition?
Actually now that you mention, I think that might be possible. When I did the test I forgot I also run guake (a quake like drop down terminal). So the history from my test could easily have been overwritten by that. When I have the time I will try to repeat the test in a cleaner environment (creating a new user and all that ...).
Am 28.03.2012 15:48, schrieb suvayu ali:
FWIW, I did the same test on a VM running F16. After restarting, this was the last thing in my .bash_history file....
echo "4 Test" ; sudo shutdown -P now
So, it isn't clear to me that it is a consistent problem. Maybe a race condition?
Actually now that you mention, I think that might be possible. When I did the test I forgot I also run guake (a quake like drop down terminal). So the history from my test could easily have been overwritten by that. When I have the time I will try to repeat the test in a cleaner environment (creating a new user and all that ...)
usually bash writes down .bash_history on close try it out with "cat ~/.bash_history" and you will not see the entries of your current session!
so if you have more than one bash-instance open all of them writing down their history and the last one wins
On 03/28/2012 09:51 AM, Reindl Harald wrote:
usually bash writes down .bash_history on close try it out with "cat ~/.bash_history" and you will not see the entries of your current session!
so if you have more than one bash-instance open all of them writing down their history and the last one wins
That behavior has always annoyed me, since I always seem to be missing useful parts of my history. Recently, someone suggested I add the following to my .bash_profile:
export HISTSIZE=5000 shopt -s histappend PROMPT_COMMAND="history -a;$PROMPT_COMMAND"
First, it increases my history size, and second, it appends the current shell's history to the file, not overwrites it, and third, it updates the history file with each command that is entered.
I am much happier now.
Woogie
suvayu ali wrote:
Hi Frantisek,
On Sat, Mar 24, 2012 at 15:15, Frantisek Hanzlik franta@hanzlici.cz wrote:
Now occurred to me that i can watch several (mainly roots) history files by incrond and start some script which log some events on it. Maybe it helps.
I recalled your post and did a check before I rebooted my laptop today (after 7 days). I think you were correct and my claim that its a ridiculous idea was wrong.
This is what I did:
- I closed all running apps except for a terminal.
- Executed these commands $ echo "1 test" $ echo "2 test" $ echo "3 test" $ sudo shutdown -P now
- On turning on the laptop again, I could not find either of the three commands with history | grep -E "echo.+test"
In addition to $HISTFILE, I log all my history to a separate file. That file _did_ have all the test and the shutdown commands. So we can conclude bash was doing the right thing and systemctl is to blame.
At the moment I am very busy, so I would urge you to file a bug report. If you post the bug id back to the list, I'll try to add more comments if I find anything with regards to this.
Hello Suvayu,
I now had a bit time for some testing, and hopefuly was able induce situation when history is always (strictly speaking, 6x in 6 tests) lost. Please see bugreport:
https://bugzilla.redhat.com/show_bug.cgi?id=811046
On machines whereon i'm now working I not succeeded to simulate it, but i did only few experiments.
Hey Frantisek,
On Tue, Apr 10, 2012 at 02:50, Frantisek Hanzlik franta@hanzlici.cz wrote:
Hello Suvayu,
I now had a bit time for some testing, and hopefuly was able induce situation when history is always (strictly speaking, 6x in 6 tests) lost. Please see bugreport:
https://bugzilla.redhat.com/show_bug.cgi?id=811046
On machines whereon i'm now working I not succeeded to simulate it, but i did only few experiments.
Thanks. I'll try to add my comments when I get some time to test.
Cheers,
On Tue, Apr 10, 2012 at 02:50:06AM +0200, Frantisek Hanzlik wrote:
suvayu ali wrote:
Hi Frantisek,
On Sat, Mar 24, 2012 at 15:15, Frantisek Hanzlik franta@hanzlici.cz wrote:
Now occurred to me that i can watch several (mainly roots) history files by incrond and start some script which log some events on it. Maybe it helps.
I recalled your post and did a check before I rebooted my laptop today (after 7 days). I think you were correct and my claim that its a ridiculous idea was wrong.
This is what I did:
- I closed all running apps except for a terminal.
- Executed these commands $ echo "1 test" $ echo "2 test" $ echo "3 test" $ sudo shutdown -P now
- On turning on the laptop again, I could not find either of the three commands with history | grep -E "echo.+test"
In addition to $HISTFILE, I log all my history to a separate file. That file _did_ have all the test and the shutdown commands. So we can conclude bash was doing the right thing and systemctl is to blame.
At the moment I am very busy, so I would urge you to file a bug report. If you post the bug id back to the list, I'll try to add more comments if I find anything with regards to this.
Hello Suvayu,
I now had a bit time for some testing, and hopefuly was able induce situation when history is always (strictly speaking, 6x in 6 tests) lost. Please see bugreport:
Please ensure your $HISTIGNORE environment variable is not set. It shouldn't be set by default, but better check anyway. ;)
Terry
-
Ed Greshko -
Franta Hanzlík -
James Wilkinson -
Lee -
Mike Wohlgemuth -
Reindl Harald -
stan -
Suvayu Ali