rc.local help

[kazakore]

I have recently upgraded RAM and fitted an SSD to my laptop and installed KXStudio on it. I have read a few guides for optimising the SSD and believed I had come up with options which should work. The thing is now I don't believe the lines I have added to rc.local are giving the behaviour I would expect.

Here is my rc.local content.:

Code: Select all

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

echo noop > /sys/block/sda/queue/scheduler
echo 6 > /sys/class/backlight/acpi_video0/brightness
/sbin/fstrim /
echo fstrim root >> /home/xxx/bootcheck.txt
/sbin/fstrim /media/xxx/Data/
echo fstrim Data >> /home/xxx/bootcheck.txt
/usr/bin/trash-empty 7
# requires trash-cli installed
echo trash >> /home/xxx/bootcheck.txt

echo 2048 > /sys/class/rtc/rtc0/max_user_freq

echo all working > /home/xxx/bootcheck.txt
exit 0

The extra echo lines are in there for fault finding. I had read that the -e option for running the script means it was stop if any command reported a failure (non-zero exit code) and thus I was trying to check if/where it stopped. Upon rebooting the file contains the "all working" so the script has run until the end.

BUT the commands don't seem to actually be doing their thing! Well the screen brightness is. I want a way to empty the Rubbish Bin on boot, so had searched for a CLI method of doing so for all partitions. Trash-cli installed and then running trash-empty seemed to be an often recommended way. The number 7 means it will delete anything over 7 days old. (Yes I could do a cron job but I also likely will change it to empty the whole Rubbish Bin once I'm a little more settled and confident.) Personally I would prefer do it on boot than periodically...

Also didn't think fstrim was working, as I ran it on the Data partition after booting and it trimmed a lot. Just realised that I tested the trash really hadn't deleted first though, so that would have added data to be trimmed by that function. Need to test that again...

Any idea why things may not be working as I would expect??


EDIT: I have moved the trash-empty line to above the fstrim lines as it makes sense, otherwise you wont trim the space made by clearing the trash.

I also confirmed that manually running "fstrim -v /" directly after booting and doing nothing but opening a terminal to type and it is still finding data to trim. Thus surely that implies it's not running correctly in the rc.local script...

[gimmeapill]

Hi,

I didn't get the full grasp of what you're doing, but it looks like you're wiping out the log with the last line.

Code: Select all

echo all working > /home/xxx/bootcheck.txt

should be instead

Code: Select all

echo all working >> /home/xxx/bootcheck.txt

BR,

LX

[glowrak guy]

The arch wiki is very well laid out. Worth a couple hours,
with format and fstab tips.
Cheers

[Frank Carvalho]

Not sure if it is a related issue, but when I had my sound card interrupt woes I made a script to configure the kernel to avoid the graphics drivers to interrupt my sound card. I put this file into rc.local as well. The problem is, that the graphics were not brought up, and did not define its irq number until later in the boot process, after rc.local had been run, which meant my script had no effect.
I was wondering if you have a similar problem with the boot order not making certain things available in time for the script?

/Frank

[kazakore]

Hi,

I didn't get the full grasp of what you're doing, but it looks like you're wiping out the log with the last line.

Code: Select all

echo all working > /home/xxx/bootcheck.txt

should be instead

Code: Select all

echo all working >> /home/xxx/bootcheck.txt

BR,

LX

To be honest I didn't really need to add the text on any of the lines, as rc.local calls the sh interpreter with "#!/bin/sh -e" it will exit if any single command in the script fails and so I would know the text comes from the last one that successfully ran. The resultant bootcheck.txt I am generating seems to imply the script has ran all the way through but my recycle bin is definitely not being emptied and as far as I can tell trim is not occurring either.

That's basically all I want, Trim (via fstrim) to operate on my SSD and to empty the recycle bin (fully or partially) every time I boot the computer.

The arch wiki is very well laid out. Worth a couple hours,
with format and fstab tips.
Cheers

That was one of the few resources I read while setting it up. They don't mention using fstrim within rc.locl on their pages[1] but for that particular part I followed this guide[2], which is aimed at Ubuntu 14.04 and derivatives. I am running KXStudio so it should be perfectly suited. It was the Arch Wiki that persuaded me to go with Noop I/O for the drive though

For the trash-empty I Googled for a way to do it on the command line (could find nothing on doing it specifically at boot/rc.local) and found mention of the tool I am using in a few places. Doesn't appear to be working from within rc.local for me though.

I did originally have just the commands, without pointing explicitly to them, which should also work (PATH should be accessible to rc.local as root) but edited that to rule it out before adding my debugging lines.

[1] https://wiki.archlinux.org/index.php/So ... rives#TRIM
[2] https://sites.google.com/site/easylinux ... by-discard

Not sure if it is a related issue, but when I had my sound card interrupt woes I made a script to configure the kernel to avoid the graphics drivers to interrupt my sound card. I put this file into rc.local as well. The problem is, that the graphics were not brought up, and did not define its irq number until later in the boot process, after rc.local had been run, which meant my script had no effect.
I was wondering if you have a similar problem with the boot order not making certain things available in time for the script?

/Frank

I doubt it. My script only has very simple commands to run on partitions. As long as the partitions are mounted and the system knows what the Trash is (and as it has PATH for commands I imagine it should do) then it should all run with no problems.

[kazakore]

The arch wiki is very well laid out. Worth a couple hours,
with format and fstab tips.
Cheers

Just clicked you said fstab. I believe the majority of my fstab edits came from reading Arch Wiki (which mostly agreed with the other sites I read but I personally think their wiki was by far the best written.)

Anyway for completeness my fstab now looks like this.

Code: Select all

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=ca434811-2d9e-4ced-b20f-854a8c87f49e /               ext4    noatime,nodiratime,errors=remount-ro 0       1
# swap was on /dev/sda7 during installation
UUID=f89e08f1-a704-474f-8cc7-eb0eb5681e16 none            swap    sw              0       0
#
# My additions!
#
# Data partition to be mounted
UUID=d444acc1-213a-4bc5-b39d-3ce2d0e76a0b       /media/dale/Data        ext4    noatime,nodiratime,errors=remount-ro    0       0
# tmpfs on RAM
tmpfs   /tmp    tmpfs   defaults,noatime,mode=1777      0       

I don't know how to test tmpfs but Data is definitely mounted (KXStudio would ask for root password when I tried to access it before adding the line.) That is the only bit important to my rc.local as far as I can tell...

[kazakore]

Nobody??

[sysrqer]

Just saw this, maybe it would help?

In my case none of the instructions were a perfect solution. If you were as unlucky as me, try this detailed one

Put all your executing code in a separate text file with an arbitrary name such as foo.sh and save it in an arbitrary place.

Add

#!/bin/sh

as first line of your code.

Try executing your foo.sh by

sudo foo.sh

to check there are no errors at all.

Provide your /etc/rc.local script with full path and name of your created script after the sh command

sh '/path/to/your/script/foo.sh'

Remember to put the above line before the last line of code

exit 0

at the end of the /etc/rc.local script.

Check first line of /etc/rc.local to be

#!/bin/sh -e

Make your /etc/rc.local executable in case it is not already executable by

sudo chown root /etc/rc.local
sudo chmod 755 /etc/rc.local

Check everything works fine by executing

sudo /etc/init.d/rc.local start

Test restart your system.

Do you not need to quote the echo parts? Now that I think about it I can't remember if it is required but it's what I always do: echo "echothis"

[kazakore]

Just saw this, maybe it would help?

In my case none of the instructions were a perfect solution. If you were as unlucky as me, try this detailed one

Put all your executing code in a separate text file with an arbitrary name such as foo.sh and save it in an arbitrary place.

Add

#!/bin/sh

as first line of your code.

Try executing your foo.sh by

sudo foo.sh

to check there are no errors at all.

Provide your /etc/rc.local script with full path and name of your created script after the sh command

sh '/path/to/your/script/foo.sh'

Remember to put the above line before the last line of code

exit 0

at the end of the /etc/rc.local script.

Check first line of /etc/rc.local to be

#!/bin/sh -e

Make your /etc/rc.local executable in case it is not already executable by

sudo chown root /etc/rc.local
sudo chmod 755 /etc/rc.local

Check everything works fine by executing

sudo /etc/init.d/rc.local start

Test restart your system.

That sounds like the kind of trick to continue running a whole script when a part of it is failing and giving a non-zero exit code. You may note both are using the sh interpreter but the rc.local uses the -e option whereas the extra script does not. (This is the option that will terminate a script as soon as any part of it has failed, rather than attempting to continue to the end.)

My echos proved it is running through until the end of the file. I'll have to test again to confirm but I think I tried running rc.local once the system was up and running and it appears to run the fstrim command at least. But maybe I forgot to ensure there was any blocks to trim so could be fooling myself. I also just ran the script direct, not via starting the init.d process (just had to read up on the differences if I'm completely honest.) Doesn't sound like it should make much difference though...

It is definitely being run at log-in. Screen brightness is set and drive is set to noop, rather than the default (think it was cfq.) It reads to the end because my bootcheck.txt has the last bit of debugging text I added to the file and thus, from my limited understanding, every line should have been executed and reported success.

Do you not need to quote the echo parts? Now that I think about it I can't remember if it is required but it's what I always do: echo "echothis"

No you don't _need_ quotation marks although it certainly is best practice! Now I've proven it reads to the end I should really remove those lines for neatness sake anyway...

[sysrqer]

No, all it means is running manually from a terminal so you can see the output of the parts that are failing, you will see errors.
I'm getting a bit lost in it all I have to say, what exactly isn't working then?

[kazakore]

No, all it means is running manually from a terminal so you can see the output of the parts that are failing, you will see errors.
I'm getting a bit lost in it all I have to say, what exactly isn't working then?

My SSD isn't being trimmed[1] with the fstrim command[2] and the Wastebin isn't being emptied (which I installed trash-cli[3] and running trash-empty[4] should do.)

As rc.local is run with the -e option it will stop running the script at any line that reports as failing! Hence why I initially added all those echo lines, assuming that at some point there was a command reporting it had failed and the rest obviously then would not run. But this showed that it did in fact get to the end of the script, so it is not due to a command "failing." Yet still they do not seem to be performing the function which they should perform!

All commands run as expected when ran explicitly from the commandline. fstrim as "sudo fstrim -v /" for Root, which is including the verbose tab so I can see the amount of space it returns to usage and confirm it definitely has done its job as it shows zero blocks the second time if I run it twice in a row. Similar with "empty-trash x" where x is the number of days to check if files are older than before removing from the wastebasket. Again easily checked it really is working when typed manually into the CLI as I can see my free space increasing. Again definitely not working from rc.local.

Maybe I should create a shutdown script and do them at shutdown rather than boot?? Really I would like to get to the bottom of why they're not working where they currently are and try and fix that though... As I mentioned earlier having fstrim in the rc.local was specifically suggested in a guide I partly followed[5], written for Ubuntu 14.04, which the distro I use (KXStudio) is itself based upon.

I meant to say I will try your idea of putting them in a separate script though. Can't hurt and if, for some reason I don't personally understand, it works when they don't in the rc.local itself then at least I would have found something that gives me the result I want, even if I unfortunately didn't understand why...

Or maybe add somewhere to the Session Startup options or whatever they are called with KDE, rather than using what I thought should be the more neat, professional and supported way. (Most useful and obvious when occasionally working across different distros.)

[1a] https://en.wikipedia.org/wiki/Trim_%28computing%29
[1b] http://blog.neutrino.es/2013/howto-prop ... d-dmcrypt/
[2] http://man7.org/linux/man-pages/man8/fstrim.8.html
[3] https://github.com/andreafrancia/trash-cli
[4] http://manpages.ubuntu.com/manpages/one ... ash.1.html
[5] https://sites.google.com/site/easylinux ... by-discard