Strange behavior with shell redirection
Hello all, sorry I don't know if I am in the good place to ask my question...
On an custom board based on the AT91SAM9260 processor, buildroot-2009.05, and jffs2 as root file system, I have an "autostart" script launched at board startup.
In this script (I use the true bash and not the busybox shell) I launch my application, and I redirect the output to a log file :
#!/bin/bash
cd /home/potentiostat
[...]
echo "Launching application" ./potentiostatApplication >> /var/log/potentiostat # Reboot if application error
if [ $? -ne 0 ]
then
reboot
fi
I use ">>" for the redirection, thus normally each time this script is launched it should concatenate the new log after the older one. But it's not the case, each time I startup the board I have a new log !!
I really don't understand this beahavior, any idea ?
Best Regards,
Cyril HAENEL
Signature · 2 lines
Cyril Haenel Registered Linux User #332632
Quoted 19 lines · Cyril HAENEL
Hello all, sorry I don't know if I am in the good place to ask my question...
On an custom board based on the AT91SAM9260 processor, buildroot-2009.05, and jffs2 as root file system, I have an "autostart" script launched at board startup.
In this script (I use the true bash and not the busybox shell) I launch my application, and I redirect the output to a log file :#!/bin/bash
cd/home/potentiostat
[...]
echo "Launching application" ./potentiostatApplication >>/var/log/potentiostat# Reboot if application error
if [ $? -ne 0 ]
then
reboot
fi
Quoted 6 lines
I use ">>" for the redirection, thus normally each time this script is launched it should concatenate the new log after the older one. But it's not the case, each time I startup the board I have a new log !!
I really don't understand this beahavior, any idea ?
What is the implementation of that "reboot"?
Yours? Something else?
It is very common that "reboot" does just exactly that, reboots. No file sync, no file closing, nothing but reboot.
Try syncing the filesystem and unmounting it before rebooting. mount -o remount <no options> <device name>
will flush the VFS buffers to disk if you don't have a "sync" available. umount <device name>
often does not flush/sync the file system, it depends on the FS. So use both of the above commands -
As to your first question -
Correct, wrong list; try a linux newbee forum.
Mike
Quoted 3 lines
Best Regards,
Cyril HAENEL
Quoted 4 lines
What is the implementation of that "reboot"?
Yours? Something else?
ls -l /sbin/reboot
lrwxrwxrwx 1 root root 14 Jul 14 12:12 /sbin/reboot ->
../bin/busybox
It's the busybox's reboot implementation
Quoted 10 lines
It is very common that "reboot" does just exactly that, reboots. No file sync, no file closing, nothing but reboot.
Try syncing the filesystem and unmounting it before rebooting. mount -o remount <no options> <device name>
will flush the VFS buffers to disk if you don't have a "sync" available. umount <device name>
often does not flush/sync the file system, it depends on the FS. So use both of the above commands -
In /etc/inittab, I have :
# Stuff to do before rebooting
null::shutdown:/usr/bin/killall klogd
null::shutdown:/usr/bin/killall syslogd
null::shutdown:/bin/umount -a -r
null::shutdown:/sbin/swapoff -a
The umount -a -r seem's to umount all mounted FS. But maybe for my jffs2 FS I also need to do a mount -o remount, I look at this, thank for the idea !
But I am not convinced that is the problem, because the board can stay alive for very long periodsof time, the log can reach several megabytes, thus I can't believe there is not at least a small part of the previous log at the next startup. I use jffs2 for that, if the FS is not correctly unmounted because a power failure for example, files are safe and contain at least the last version of the file before the power failure.
Quoted 3 lines
As to your first question -
Correct, wrong list; try a linux newbee forum.
I fact I am not a newbee at all in linux, if I asked my question here, it's really because I now that the problem I have doesn't exist on my laptop for example !!
Regards,
Cyril
Signature · 2 lines
Cyril Haenel Registered Linux User #332632
Quoted 27 lines · Cyril HAENEL
Quoted 4 lines
What is the implementation of that "reboot"?
Yours? Something else?ls -l
/sbin/reboot
lrwxrwxrwx 1 root root 14 Jul 14 12:12/sbin/reboot->
../bin/busyboxIt's the busybox's reboot implementation
Quoted 10 lines
It is very common that "reboot" does just exactly that, reboots. No file sync, no file closing, nothing but reboot.
Try syncing the filesystem and unmounting it before rebooting. mount -o remount <no options> <device name>
will flush the VFS buffers to disk if you don't have a "sync" available. umount <device name>
often does not flush/sync the file system, it depends on the FS. So use both of the above commands -In
/etc/inittab, I have :# Stuff to do before rebooting
null::shutdown:/usr/bin/killall klogd
null::shutdown:/usr/bin/killall syslogd
null::shutdown:/bin/umount -a -r
null::shutdown:/sbin/swapoff -a
Quoted 8 lines
The umount -a -r seem's to umount all mounted FS. But maybe for my jffs2 FS I also need to do a mount -o remount, I look at this, thank for the idea !
But I am not convinced that is the problem, because the board can stay alive for very long periodsof time, the log can reach several megabytes, thus I can't believe there is not at least a small part of the previous log at the next startup.
Well, at least one or more erase blocks worth anyway. jffs2 does a lot of buffering, it could be that the journal is just rolling back the file to when it was created.
Also, writing erase blocks is relatively slow (on a cpu time scale) - could be that the system is shutting down before jffs2 has time to get all of the work done. I.E: its only valid checkpoint is when the file was first created.
What about the other log files? The ones created by syslogd? Are they complete up to the time of reboot?
Did you include logger in the Busybox build?
Can you log your application output with logger so it can be handled by syslogd?
Are you running with the syslogd circular buffer in RAM?
Quoted 10 lines
I use jffs2 for that, if the FS is not
correctly unmounted because a power failure for example, files are safe and contain at least the last version of the file before the power failure.Quoted 3 lines
As to your first question -
Correct, wrong list; try a linux newbee forum.I fact I am not a newbee at all in linux, if I asked my question here, it's really because I now that the problem I have doesn't exist on my laptop for example !!
I bet your laptop doesn't use flash for its secondary storage. More likely it uses a disk drive of some sort; for example. ;)
So unless your laptop is running embedded Linux with flash as its only storage - - -
You are trying to compare grapes with watermelons.
Mike
Quoted 5 lines
Regards,
Cyril
Hello,
Le Fri, 18 Dec 2009 13:10:41 +0100,
Cyril HAENEL <[email protected]> a ?crit :
Quoted 1 line
./potentiostatApplication >>
/var/log/potentiostat
In the default Buildroot target skeleton, /var/log is a symbolic link to /tmp, and /tmp is mounted as a tmpfs (the contents of the filesystem are stored into memory).
So with the default Buildroot configuration, the contents of /var/log (and many other /var directories) are lost when you reboot.
Cheers,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com
Quoted 5 lines
In the default Buildroot target skeleton,
/var/logis a symbolic link to /tmp, and /tmp is mounted as a tmpfs (the contents of the filesystem are stored into memory).
Quoted 7 lines
So with the default Buildroot configuration, the contents of
/var/log(and many other /var directories) are lost when you reboot.Cheers,
Thomas
Yesss ! Thank, It is the problem ! Thus it's a big problem because what will be the result when the memory will be full !?
Regards,
Cyril
Signature · 2 lines
Cyril Haenel Registered Linux User #332632
Quoted 8 lines · Cyril HAENEL
Quoted 8 lines
In the default Buildroot target skeleton,
/var/logis a symbolic link to /tmp, and /tmp is mounted as a tmpfs (the contents of the filesystem are stored into memory).So with the default Buildroot configuration, the contents of
/var/log(and many other /var directories) are lost when you reboot.
Quoted 7 lines
Quoted 4 lines
Cheers,
Thomas
Yesss ! Thank, It is the problem ! Thus it's a big problem because what will be the result when the memory will be full !?
tmpFS uses swap as its backing store. How much swap do you have? By default tmpFS will only use 50% of it.
Also, you can limit the amount of ram used by tmpFS on the mount command and/or fstab.
Mike
Quoted 3 lines
Regards,
Cyril
Quoted 8 lines
tmpFS uses swap as its backing store. How much swap do you have? By default tmpFS will only use 50% of it.
Also, you can limit the amount of ram used by tmpFS on the mount command and/or fstab.
Mike
I have no swap at all :
# cat /etc/fstab # /etc/fstab: static file system information. # # <file system> <mount pt> <type> <options> <dump> <pass> /dev/root / ext2 rw,noauto 0 1 proc /proc proc defaults 0 0 devpts /dev/pts devpts defaults,gid=5,mode=620 0 0 tmpfs /tmp tmpfs defaults 0 0 sysfs /sys sysfs defaults 0 0
Curious, for / it gives ext2, but in fact it's jffs2....
# df Filesystem Size Used Available Use% Mounted on /dev/root 508.0M 20.4M 487.6M 4% / tmpfs 30.5M 1.6M 29.0M 5% /tmp
Thanks for the informations, in the next release, I will write my log in /home/potentiostat/ and not /var/log/ !
Cyril
Signature · 2 lines
Cyril Haenel Registered Linux User #332632