No matter what setting I give Sass for caching, a cache is still created:
# in sinatra
set :sass, { :cache => false }
# after running the app
$ ls -al
drwxr-xr-x 3 iainuser iainuser 102 20 Jan 17:33 .sass-cache
Is there something else I need to do to stop the caches being created? Any insight is much appreciated.
SASS v3.1.12, Sinatra v1.3.1
Related
I'm trying to build a yocto image without busybox and without any busybox
applet deployed.
I have tried that configuring my distro.conf file in this way:
DISTRO_FEATURES_remove = " busybox"
VIRTUAL-RUNTIME_base-utils = ""
PREFERRED_PROVIDER_virtual/base-utils = ""
Nonetheless, busybox binary and two related applets (syslog and udhcpc) are
installed in the generated image:
$ rpm -qa | grep busybox
busybox-syslog-1.24.1-r0.corei7_64
busybox-1.24.1-r0.corei7_64
busybox-udhcpc-1.24.1-r0.corei7_64
I have tried disabling syslog applet appending to my distro.conf file:
VIRTUAL-RUNTIME_syslog ?= ""
But syslogd applet is still installed:
# ls -l /sbin/syslogd
lrwxrwxrwx 1 root root 19 Feb 15 14:03 /sbin/syslogd -> /bin/busybox.nosuid
Is there some way to remove busybox completely from the generated image?
You need to break apart packagegroup-core-boot:
make a copy of it;
remove busybox from it;
make your image inherit it instead of the original.
Finally I found the right answer to my question. The trick to disable busybox completely is defining these variables in the distro.conf file:
VIRTUAL-RUNTIME_base-utils = ""
VIRTUAL-RUNTIME_login_manager = "shadow"
Last variable (login_manager) is only needed if you install "packagegroup-core-boot" in your custom image, such as in my case.
So, this question is solved. Thank you so much for all your support! :-)
I have about 400MB sized berkeley db file.
$> ls -alh ses.db
-rw-rw-r-- 1 junyoung junyoung 391M 9월 23 17:32 ses.db
after dumping it, I've checked the size again.
$> db_dump ses.db > ses.db.dump
$> ls -alh ses.db.dump
-rw-rw-r-- 1 junyoung junyoung 2.2M 9월 23 18:09 ses.db.dump1
the result file size is too small than I expected.
what's the reason of this? any comments?
There could be many reasons for this, to be sure. But possibly the most common reason is that the database once held many more records which were later deleted. This space is not returned to the filesystem.
See this thread in the Oracle forums for more information https://community.oracle.com/thread/879030 . And, as it says in there, try the db_stat command to get some visibility into what's going on in your database.
I'm initializing spot instances running a derivative of the standard Ubuntu 13.04 AMI by pasting a shell script into the user-data field.
This works. The script runs. But it's difficult to debug because I can't figure out where the output of the script is being logged, if anywhere.
I've looked in /var/log/cloud-init.log, which seems to contain a bunch of stuff that would be relevant to debugging cloud-init, itself, but nothing about my script. I grepped in /var/log and found nothing.
Is there something special I have to do to turn logging on?
The default location for cloud init user data is already /var/log/cloud-init-output.log, in AWS, DigitalOcean and most other cloud providers. You don't need to set up any additional logging to see the output.
You could create a cloud-config file (with "#cloud-config" at the top) for your userdata, use runcmd to call the script, and then enable output logging like this:
output: {all: '| tee -a /var/log/cloud-init-output.log'}
so I tried to replicate your problem. Usually I work in Cloud Config and therefore I just created a simple test user-data script like this:
#!/bin/sh
echo "Hello World. The time is now $(date -R)!" | tee /root/output.txt
echo "I am out of the output file...somewhere?"
yum search git # just for fun
ls
exit 0
Notice that, with CloudInit shell scripts, the user-data "will be executed at rc.local-like level during first boot. rc.local-like means 'very late in the boot sequence'"
After logging in into my instance (a Scientific Linux machine) I first went to /var/log/boot.log and there I found:
Hello World. The time is now Wed, 11 Sep 2013 10:21:37 +0200! I am
out of the file. Log file somewhere? Loaded plugins: changelog,
kernel-module, priorities, protectbase, security,
: tsflags, versionlock 126 packages excluded due to repository priority protections 9 packages excluded due to repository
protections ^Mepel/pkgtags
| 581 kB 00:00
=============================== N/S Matched: git =============================== ^[[1mGit^[[0;10mPython.noarch : Python ^[[1mGit^[[0;10m Library c^[[1mgit^[[0;10m.x86_64 : A fast web
interface for ^[[1mgit^[[0;10m
...
... (more yum search output)
...
bin etc lib lost+found mnt proc sbin srv tmp var
boot dev home lib64 media opt root selinux sys usr
(other unrelated stuff)
So, as you can see, my script ran and was rightly logged.
Also, as expected, I had my forced log 'output.txt' in /root/output.txt with the content:
Hello World. The time is now Wed, 11 Sep 2013 10:21:37 +0200!
So...I am not really sure what is happening in you script.
Make sure you're exiting the script with
exit 0 #or some other code
If it still doesn't work, you should provide more info, like your script, your boot.log, your /etc/rc.local, and your cloudinit.log.
btw: what is your cloudinit version?
I've seen a lot of questions about pre 1.6 Magento installations to the most recent version (at the current moment 1.7.0.2) but there are a lot of answers that don't work for everybody.
So below the answer to the question:
How to upgrade Magento from a pre 1.6 installation to the most recent one.
There are a lot of versions and not all of them are working. This one has worked for me for a lot of versions, as far as 1.3 to 1.7.
Please add comments with solutions to problems you're experiencing, I can update the answer so other people get help from this topic too!
What you need:
- SUDO rights/root account on your server.
- The linux package 'nohub'
- make sure NOBODY can trigger the index.php. If your version supports maintenance.flag, put an empty maintenance.flag file in your Magento root.
Walkthrough
1) Download the latest Magento. Overwrite: ./download/* ./lib/* ./mage
2) Run these steps from you Magento root als SUDOer (if you're not root, put 'sudo' for all the commands)
find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;
chmod -R 777 ./var
chmod 550 mage
3) Go to your Magento root folder and type:
./mage list-upgrades
./mage config-set preferred_state stable
./mage upgrade-all --force
./mage install http://connect20.magentocommerce.com/community Mage_All_Latest --force
4) Now there is the last step. Note: In some situations this process can take up to 8+ hours!
nohup php -f ./index.php
Known issues
1) it's possible that your update gets in a loop. To find this loop, enable debugging.Edit: /lib/Varien/Db/Adapter/Pdo/Mysql.php (+/- line 112 and 112)
protected $_debug = true;
protected $_debuglogeverything = true;
This will write a debug to: /var/debug/[debug_file]
2) Read the file by opening the dir:
cd /var/debug/[debug_file] <-- replace with the actual filename
tail -f [debug_file]
3) If you use debug, the file will get HUGE! Make sure you delete it once in a while.
Tip: as a root user, type:
crontab -e
*/5 * * * * rm /[my_magento_base_folder]/var/debug/[debug_file] <-- add this line
If you want to read the file, add a # to this line and use tail to read it.
These steps help you find common errors and loops (if the tail shows a repeating error message)
I am trying to generate a screenshot of a firefox window in my terminal, but I keep getting an error:
root#host [~]# DISPLAY=:1 firefox http://www.cnn.com & sleep 5 && DISPLAY=:1 import -window root -crop 1264x948+0+25 -quality 90 /usr/local/apache/htdocs/screenshot1.jpg && pkill firefox
[1] 30200
import: unable to open X server `:1' # import.c/ImportImageCommand/364.
Why is this happening? How can I fix it?
Maybe try DISPLAY=:0, for example?
It looks like you used changed to root in the terminal after starting it (or did you login to X as root?). If that's the case the display can't be opened because it's owned by another user and you can't just go and display stuff somebody else's display.
Exit the root session and it will probably work. If you want it to work from the root session take a look at 'man xhost'.
Can you tell us what are the result when you type
ls -la /tmp/ | grep X
and
ps | grep X
Also, I had some trouble with using the DISPLAY=:1 syntax, so instead I use:
firefox --display=:1 URL_OF_SITE
import -display :1 -window root etc...