[Buildroot] Strange behavior with shell redirection

[Buildroot] Strange behavior with shell redirection

[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

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

-- 

Cyril Haenel
Registered Linux User #332632

[Buildroot] Strange behavior with shell redirection

[Michael S. Zick]

On Fri December 18 2009, Cyril HAENEL wrote:
> 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 ?
> 

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

> Best Regards,
> Cyril HAENEL
> 

[Buildroot] Strange behavior with shell redirection

[Cyril HAENEL]

> 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
> 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.

> 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


-- 

Cyril Haenel
Registered Linux User #332632

[Buildroot] Strange behavior with shell redirection

[Michael S. Zick]

On Fri December 18 2009, Cyril HAENEL wrote:
> 
> > 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
> > 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. 
>

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?

> 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.
> 
> > 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
> 
> Regards,
> Cyril
> 
> 

[Buildroot] Strange behavior with shell redirection

[Thomas Petazzoni]

Hello,

Le Fri, 18 Dec 2009 13:10:41 +0100,
Cyril HAENEL <chaenel@free.fr> a ?crit :

> ./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
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com

[Buildroot] Strange behavior with shell redirection

[Cyril HAENEL]

> 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
>   
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

-- 

Cyril Haenel
Registered Linux User #332632

[Buildroot] Strange behavior with shell redirection

[Michael S. Zick]

On Fri December 18 2009, Cyril HAENEL wrote:
> 
> > 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
> >   
> 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
> Regards,
> Cyril
> 

[Buildroot] Strange behavior with shell redirection

[Cyril HAENEL]

> 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

-- 

Cyril Haenel
Registered Linux User #332632