Reply
Thread Tools
Posts: 181 | Thanked: 82 times | Joined on Jan 2010
#1
Since the last week I have found that the log file /var/log/maemo-optify-boottime.log is growing with a new record on every boot. The records are like this:
2012-10-31 18:05:25 :: not enough free space in /home (need at least 200 MB free), quitting.
1+0 records in
1+0 records out
512 bytes (512B) copied, 1.222565 seconds, 418B/s

The script which is generating the log is /usr/sbin/maemo-optify-auto-opt.sh, which calls the function dfree inside /usr/sbin/maemo-optify-lib.sh. dfree function is as follows

Code:
dfree()  
 {  
   space=`/bin/busybox stat -ft /home | /bin/busybox awk '{print int($5*$9/(1024*1024)) }'`  
   [ $? -ne 0 ] && return 0  
   return $space  
 }
If you execute the command
Code:
stat -ft /home | awk '{print int($5*$9/(1024*1024)) }'
you get two integers, not only one, and the last one is 0 (the first one is 512 in my phone). Indeed, I have made an script to see the value of the returned $space variable, and it is 0!!! Obviously I have plenty of space in /home directory. I cannot understand why it happens only since the last week. Any idea?

On the other hand, I do not know where the /usr/sbin/maemo-optify-auto-opt.sh is called from on every boot of the phone. The file checks if everything is optified, and it is not required now.

Thanks in advance.
 

The Following User Says Thank You to ikerrg For This Useful Post:
Posts: 1,808 | Thanked: 4,272 times | Joined on Feb 2011 @ Germany
#2
@ikerrg,

(I just answered this on the other thread "Random reboot..")

Very interesting analysis. I don't have /usr/sbin/maemo-optify-auto.sh (but I may have removed many Nokia packages). Could you please do "dpkg -S /usr/sbin/maemo-optify-auto.sh" to see from which package this thing is coming?

Furthermore, that way of checking space using stat seems quite broken.

$5 is the block size, but
$9 is the total number of inodes

so the dfree() function is mixing apples with bananas

It should either use df[*] or replace $9 with $8, which is the number "available blocks" ($9 is the number of "free blocks", don't know what the difference may be).

Plus I don't know why awk returns two values when multiplying. Seems that busybox is way beyond broken (I tested with latest busybox-power).[*]
Code:
dfree()  
 {  
   space=`df -B 1 | tail -1 | awk '{ print $4 }' `  
   [ $? -ne 0 ] && return 0  
   return $space  
 }
Good luck.

PS: I do have (in my most "normal" N900) a /var/log/maemo-optify-boottime.log, last modified about 8 months ago. Nothing in the boot process seems to be touching it, so it must have come from some package that I have uninstalled.
 

The Following User Says Thank You to reinob For This Useful Post:
Posts: 181 | Thanked: 82 times | Joined on Jan 2010
#3
@reinob

The file /var/log/maemo-optify-boottime.log is coming from the package maemo-optify-runonce. Why you don't have it installed? It is odd, I have not changed any official package in my device and it is reflashed one month ago with the latest rootfs and eMMC images.
In addition, I do not understand why since the last week a process is executing this file on boot. How can I find where it is called on booting?

Last edited by ikerrg; 2012-11-08 at 09:30.
 

The Following User Says Thank You to ikerrg For This Useful Post:
Posts: 1,808 | Thanked: 4,272 times | Joined on Feb 2011 @ Germany
#4
Originally Posted by ikerrg View Post
@reinob

The file /var/log/maemo-optify-boottime.log is coming from the package maemo-optify-runonce. Why you don't have it installed? It is odd, I have not changed any official package in my device and it is reflashed one month ago with the latest rootfs and eMMC images.
Well, I guess the "runonce" made me decide to uninstall it. If it was (pre-)installed and did its thing already ("once"), then why should it continue to be installed polluting my dpkg database

In addition, I do not understand why since the last week a process is executing this file on boot. How can I find where it is called on booting?
AFAIK in /etc/event.d/rcS-late (where /home is mounted) and (where one of the possibilities for *generating a reboot loop* is present -- "if fail to mount /home and system already optified")

When /home is mounted OK and not in ACT_DEAD mode /usr/sbin/maemo-optify-firstboot.sh is called.

Then /opt is mounted, and then /usr/sbin/maemo-optify-auto-opt.sh is called (if it exists).

So I guess the script (if it exists) runs at *every* boot, makes a messy calculation of a bogus number and logs it in a file taking space in rootfs (not much, but hey..)

I'd suggest you just uninstall every package containing the string "optify" *except* pymaemo-optify. That's a whole different beast, and I still have to find a nice way of having optified-python without all that bind-mounting party.
 

The Following 2 Users Say Thank You to reinob For This Useful Post:
Posts: 181 | Thanked: 82 times | Joined on Jan 2010
#5
Thanks again! I will try to play with the booting process to learn a bit more And also I will consider removing optify packages, though maemo-optify-runonce is considered that it is used for when you update your rootfs, to be sure that everything is optified.

Anyway, you said that in your most "normal" N900 you also have the file /usr/sbin/maemo-optify-auto-opt.sh . If it is being executed on every boot like in my N900, why in your device it is not logging anything into /var/log/maemo-optify-boottime.log? I think the calculation of the bogus number should be the same in your device as in my device.
Something should have changed in my phone in the last week because the logfile had no records from before, and now it is growing.
 
Posts: 1,808 | Thanked: 4,272 times | Joined on Feb 2011 @ Germany
#6
Originally Posted by ikerrg View Post
Thanks again! I will try to play with the booting process to learn a bit more And also I will consider removing optify packages, though maemo-optify-runonce is considered that it is used for when you update your rootfs, to be sure that everything is optified.
Well, I don't (still) know what exactly those packages "optify", i.e. how they decide which file/folder to move away and symlink. It might be useful, but most probably not

Anyway, you said that in your most "normal" N900 you also have the file /usr/sbin/maemo-optify-auto-opt.sh.
Nope. I said I have the log in /var/log but not the script in /usr/sbin. In fact, thanks for reminding me to delete that log

Something should have changed in my phone in the last week because the logfile had no records from before, and now it is growing.
From what I've been able to read from the .deb the script will check if the log has reached a certain size, and if so, delete it and start again. Probably this is what happened to you, and you just happened to notice that log file after the first log/previous logs had already been deleted.

If you find anything interesting, let us (at least me know!
 

The Following 2 Users Say Thank You to reinob For This Useful Post:
Posts: 181 | Thanked: 82 times | Joined on Jan 2010
#7
Originally Posted by reinob View Post
Well, I don't (still) know what exactly those packages "optify", i.e. how they decide which file/folder to move away and symlink. It might be useful, but most probably not
You have more info about the set of scripts in http://maemo.gitorious.org/maemo-af/...e/trees/master
The file maemo-optify-auto-opt.conf shows what is checked for optification. Not very useful.

Originally Posted by reinob View Post
From what I've been able to read from the .deb the script will check if the log has reached a certain size, and if so, delete it and start again. Probably this is what happened to you, and you just happened to notice that log file after the first log/previous logs had already been deleted.
OK, I think you got it!!! This must be the reason. So it is a bogus code in the original maemo scripts!!

Originally Posted by reinob View Post
If you find anything interesting, let us (at least me know!
Only one thing about your code. The dfree function outputs the free size (at least it should) in MiB. So you should change your code to:
Code:
dfree()  
 {  
   space=`df -B 1 | tail -1 | awk '{ print int($4/(1024*1024)) }' `  
   [ $? -ne 0 ] && return 0  
   return $space  
 }
Very smart code, indeed!! I will change it in the original script and check what happens.

Regarding your optimizations in your N900, it would be very interesting if your write a guide about which packages, boot scripts and whatever can be removed/commented in order to make N900 faster. It seems very interesting for me!!

Last edited by ikerrg; 2012-11-08 at 10:39.
 

The Following 3 Users Say Thank You to ikerrg For This Useful Post:
Posts: 181 | Thanked: 82 times | Joined on Jan 2010
#8
@reinob

Although the updated code for dfree works in the commandline and shows the space available (25450 MiB for me), it shows a different value when executed from inside a script. I have made a test script trying to understand what the boot time script is really getting:

Code:
#!/bin/sh
. /usr/sbin/maemo-optify-lib.sh
dfree "/home"
echo $?
It uses the same codes as the original script to call the dfree function. For me, the result of this script is 144 MiB, lower than the required 200 MiB, and therefore the message is still being logged to the file on boot time. Any idea? I'm not expert on linux scripts.

Thanks.

Last edited by ikerrg; 2012-11-08 at 11:08.
 
Posts: 181 | Thanked: 82 times | Joined on Jan 2010
#9
Well, this is becoming a challenge for me. I have changed the dfree function to include the path to search for space in. ($1)

Code:
dfree()  
 {  
   space=`df -B 1048576 $1 | tail -1 | awk '{ print int($4) }' `  
   [ $? -ne 0 ] && return 0  
   return $space  
 }
Now it perfectly returns the value of the rootfs free space (dfree "/"), but it fails for /home space. When called from my test script, I get about 70 MiB for / free space, but only 167MiB for /home free space, even when a direct commandline call to
df -B 1048576 /home | tail -1 | awk '{ print int($4) }' shows 1447 MiB. What could be the problem? Is the problem in my test script (the echo $? command)?

Thanks.

P.D.
It seems that if I modify my test script echoing the dfree result as $space instead of $?, the value returned is correct.
Code:
#!/bin/sh
. /usr/sbin/maemo-optify-lib.sh
dfree "/home"
echo $space
However, the original maemo script (/usr/sbin/maemo-optify-auto-opt.sh) is using the method $?, and therefore it cannot get the correct value for the free space. Am I right? Why $? method works for rootfs free space (70) and not for /home free space (1447)?

Last edited by ikerrg; 2012-11-08 at 11:52.
 
Posts: 1,808 | Thanked: 4,272 times | Joined on Feb 2011 @ Germany
#10
Weird. Just as a test, change the command to

df -m $1 | tail -1 | awk ' { print $4 } '

with -m you get the megabytes directly. I suspect int() may be doing something weird.
 

The Following User Says Thank You to reinob For This Useful Post:
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 22:59.