Μια φοβερη εφαρμογη για backup στο ubuntu, ειναι το “Back in time”. Αν εχετε επαφη με Mac ισως εχετε ακουστα το πολυ καλο, Time Machine. Και τα δυο προγραμματα δουλευουν με τον περιπου ιδιο τροπο. Ρυθμιζεται ποιους φακελους και αρχεια θελετε να κανετε backup, που να σωθει το backup και τη συχνοτητα που θελετε να περνετε τα backups.

Πολυ απλο στην λειτουργια του και ελαφρυ για τον υπολογιστη. Χρησιμοποιει τον cron για να περνει τα backups στα καθορισμενα χρονικα διαστηματα και ουτε που θα καταλαβετε οτι δουλευει στο background. Για να το εγκαταστησετε:

sudo apt-get install backintime-gnome

Δειτε και το παρακατω video:

http://www.youtube.com/watch?v=hcnNzrta7Jc

Hello everyone. This is my first post here, and I’m looking for some guidance so I may give some guidance of my own hopefully.

I am on a RHEL server running the latest version but highly modified version of Scientific Linux.
I have install all the necessary packages to run ffmpeg and qt-faststart.
I run the video-verify-ffmpeg.php script and it runs successfully, I get the final message Congratulations! ffmpeg is installed correctly.
I even run the ffmpeg command on multiple files to test outside of php, and it all runs smoothly so from what I can see the transcoder is fine.
As for WPMU, I have it installed on the same server, and I have setup the table correctly, copied all the necessary files, and checked and rechecked my path environments.
What happens is that when I upload a video through the backend. I get a message saying:
“This video is being processed
It will be ready in about 5 hours.”

Now this whole framework is new to me, so I was thinking this is quite a long time so I let it run overnight. I come back the next day and it says: “Video will be ready in a few minutes”. Clearly something was wrong, it had been over 12 hours.
I tried again with various file types and sizes, all the same thing, an eta of about 5 hours, then it never finishes.

I figured it has to do with something with cron jobs. I haven’t ran any on this server, and was wondering if I may be missing to other packages I am unaware of.

Here is a link to my staging server to a post after I uploaded the same file the verify script uses, “baby.wmv”.

The time does seem to decrease, but it never finishes so please don’t bother to wait or anything. I really don’t know where to start debugging this, if anyone has a direction, I’m all ears.

Thanks.

Today was a bit more complex then yesterday and I was feeling lazy so I caved in and had some faux meat products.

I Had:
40g Raisins
2 small granny smith apples w/ skin
12fl oz coffee w/ 2 Tbsp hazelnut silk creamer
1 MorningStar Riblet
2.5 small red potatoes mashed w/ “mayo”, dijon mustard, tofutti sour cream, fake bacon bits (all those in very small amounts)
1 big can of creamed corn (I was being lazy)
3/4 cup cooked brown rice lg
12fl oz Almond Breeze

Here is how it came out:
(Click to see full image)

_________

I feel so so today. I had a lazy start to my day and my head hurts.  My ratio was 9/82/9 which I think is a better ratio; yes a lot of it came from nonfresh fruits/veggies, but I’m kinda out of supplies so I’m making due til next month. I’m on a budget!  Oh.. ps… its still cold here!! I guess its winter so it could be worse.

So today was pretty small and simple. Maybe I should do this more often, who knows.

I had:
20fl oz cranberry juice
1/3 cup. pomelo
1/3 of my leftover homemade pizza
two small granny smith apples
3 Tablespoons of raisins, seeded
12fl oz chocolate almond milk

Here is how the counts broke out to:

—–

Overall I felt good today, I was sluggish because I did oversleep a little. My meals were simple and that was okay. Maybe I should do it more often, I dunno. My back is really hurting today so I couldn’t even consider a form of exercise, and I’ve chosen not to weigh myself today. Or do anything any measurements. I was also in a good mood today. My only complaint would be its too cold here.

Come detto in un post precedente (questo), il bootloader ADAM2 che trovate su molti modem/router (fra i quali Dlink )  è soggetto ad una frequente “deframmentazione” della env, cioè della partizione (mtd3) contenente le variabili di sistema, e questo problema può portare il modem/router in “stallo”.

Per porre rimedio a questo problema il team routertech ha approntato nell’ultima versione del firmware (2.91.1) lo script “auto_defragenv.sh” che controlla il livello di deframmentazione rispetto ad un valore di soglia (di default 30) e se superiore, deframmenta la env.

Lo script va avviato a mano (usando la schermata “Run Command”), oppure si può settare cron in modo che avvii il controllo ad intervalli regolari.

Nel mio caso ho scelto di far eseguire il controllo ogni domenica alle 23.30, ed ho impostato il tutto eseguendo il comando:

cronjob-env.sh “auto_defragenv.sh&” “30″ “23″ “*” “*” “0″ “RT_cmd_2″

cronjob-env.sh crea un nuovo job nella crontab ed inoltre “associa” una variabile a questo nella env, nel mio caso ho dato il nome “RT_cmd_2″: in questo modo anche in caso di riavvii, l’impostazione rimane memorizzata.

Welcome to Episode 9. In this episode, we shall be looking at how you can run background tasks in your GAEJ Application. By background Task, I mean any piece of code that you would like to run at a scheduled time and independent of the user interaction.There are several examples of such tasks. For e.g. :

• Hourly/Daily/Weekly/Monthly backup of data
• End of the day report generation to report any errors, transactions, etc.
• Sending an email at the end of the day (or once a day) with some information to subscribers. For e.g. News sites.

If you have written a few web applications, you would definitely have come across more scenarios like that.

In this episode, we shall cover the following:

1. What is a Cron Job?
2. How to schedule a Cron Job?
3. Write a simple Cron Job that prints a single statement
4. Configure, execute and monitor the Cron Job execution

Let’s go!

What is a Cron Job? When would you need one?

I will use information liberally from Wikipedia over here to explain some of the core concepts. You can refer to the Cron page at Wikipedia if you want.

The word ‘cron’ is short for Chronograph. A Cron is a time-based job scheduler. It enables our application to schedule a job to run automatically at a certain time or date. A Job (also known as a Task) is any module that you wish to run. This module can perform system maintenance or administration, though its general purpose nature means that it can be used for other purposes, such as connecting to the Internet and downloading email.

Examples include:

• Taking a daily backup of data via a scheduled task and moving the file to another server. (Runs once daily)
• Sending an email every week to your subscribers. (Runs once weekly)
• Clearing the log files at the end of every day (Runs once daily)
• Remind yourself of a wonderful weekend coming up, every Friday at 5:00 PM (Runs once a week on a Friday at 5:00 PM)

The Google App Engine provides a service called the Cron Service that helps us do two fundamental things:

1. Allows your application to schedule these tasks.
2. Execute these tasks based on their schedule.

What does a Cron Job look like? And how do I schedule one?

A Cron Job is nothing but a URL that is invoked by the Google App Engine infrastructure at its scheduled execution time. To write a Cron Job, you need to do the following:

1. Write a Java Servlet and configure it in the web.xml. Note down the URL where the servlet can be invoked. The URL is the <url-pattern> mentioned in the <servlet-mapping> for your Servlet configuration in web.xml. For e.g.  the URL is the <url-pattern> element specified in the segment of the web.xml that is shown below:

<servlet>
 <servlet-name>GAEJCronServlet</servlet-name>
 <servlet-class>com.gaejexperiments.cron.GAEJCronServlet</servlet-class>
 </servlet>

<servlet-mapping>
 <servlet-name>GAEJCronServlet</servlet-name>
 <url-pattern>/cron/mycronjob</url-pattern>
 </servlet-mapping>

2. Create a cron.xml file that specifies one or more Cron Jobs (Scheduled Tasks) that you want to execute. A sample for the above Cron Job is shown below:

<?xml version="1.0" encoding="UTF-8"?>
<cronentries>
 <cron>
 <url>/cron/mycronjob</url>
 <description>Put your Cron Job description here</description>
 <schedule>Put Cron Job Schedule here</schedule>
 </cron>
</cronentries>

The cron.xml file tells Google App Engine about the Cron Jobs that are scheduled by your application. This file resides in the WEB-INF directory of your application and is copied to the App Engine cloud when you deploy the application. The following points are important about the cron.xml file:

1. Each Cron Job configured in your application is defined in a <cron/> element. So there can be one or more <cron/> elements.
2. The above <cron/> element has the following 3 elements that defines the Job.
   • <url/> specifies where the Google App Engine can invoke your Cron Job. This is nothing but the Servlet URL that you defined in the web.xml file that we saw earlier.The Servlet URL will point to your Servlet which contains the Cron Job implementation.
   • <description/> is a simple text based description of what your Cron Job does. It does not influence any aspect of the execution and is used for display purposes when you look at your application configuration via the App Console.
   • <schedule/> is the time when your Job has to be executed. This is where you specify if your job is to be run daily, once every hour, on Friday at 5:00 PM, etc. It is completely dependent on when you wish to execute this job. However, you must follow some rules and they are specified in the documentation on Scheduling Format. I strongly recommend you to read it up to understand various ways of specifying the schedule. Some of the examples are: “every 1 minute”, “every 12 hours”, “every friday 17:00″ and so on.

Develop a simple Cron Job

The first thing to do is to create a New Google Web Application Project. Follow these steps:

1. Either click on File –> New –> Other or press Ctrl-N to create a new project. Select Google and then Web Application project. Alternately you could also click on the New Web Application Project Toolbar icon as part of the Google Eclipse plugin.

2. In the New Web Application Project dialog, deselect the Use Google Web Toolkit and give a name to your project. I have named mine GAEJExperiments. I suggest you go with the same name so that things are consistent with the rest of the article, but I leave that to you. In case you are following the series, you could simply use the same project and skip all these steps altogether. You can simply go to the next part i.e. the Servlet code.

3. Click on Finish. This will generate the project and also create a sample Hello World Servlet for you. But we will be writing our own Servlet.

GAEJCronServlet.java

Our Cron Job is going to be very simple. It is simply going to print out a statement in the log file that says that it is getting executed. The Cron Service of Google App Engine automatically will invoke this Servlet when its scheduled time to execute has arrived. So all we need to do is code out Servlet. The code is shown below:

package com.gaejexperiments.cron;

import java.io.IOException;
import java.util.logging.Logger;

import javax.servlet.ServletException;
import javax.servlet.http.*;

@SuppressWarnings("serial")
public class GAEJCronServlet extends HttpServlet {
 private static final Logger _logger = Logger.getLogger(GAEJCronServlet.class.getName());
 public void doGet(HttpServletRequest req, HttpServletResponse resp)
 throws IOException {

 try {
 _logger.info("Cron Job has been executed");

 //Put your logic here
 //BEGIN
 //END
 }
 catch (Exception ex) {
 //Log any exceptions in your Cron Job
 }
 }

 @Override
 public void doPost(HttpServletRequest req, HttpServletResponse resp)
 throws ServletException, IOException {
 doGet(req, resp);
 }
}

The code is straightforward to understand. It has doGet() and doPost() methods. And you will find in the doGet() method, that we simply log with an INFO level, that the Cron Job has been executed. In fact, your actual Job implementation should go in here as indicated by the comments. So whether you are invoking a backend database, or sending a consolidated email report, etc should all go in here.

All that remains is to now tell the App Engine via configuration about your Servlet (via web.xml) and create the cron.xml file in which you will mention your Cron Job.

Configure the Cron Job

As mentioned, we need to configure the Servlet in the web.xml and also specify it in the cron.xml file. Let us look at that now:

Configuring the Servlet

We need to add the <servlet/> and <servlet-mapping/> entry to the web.xml file. This file is present in the WEB-INF folder of the project. The necessary fragment to be added to your web.xml file are shown below. Please note that you can use your own namespace and servlet class. Just modify it accordingly if you do so.

 <servlet>
   <servlet-name>GAEJCronServlet</servlet-name>
   <servlet-class>com.gaejexperiments.cron.GAEJCronServlet</servlet-class>
 </servlet>

 <servlet-mapping>
   <servlet-name>GAEJCronServlet</servlet-name>
   <url-pattern>/cron/gaejcronjob</url-pattern>
 </servlet-mapping>

Specifying the Cron Job (cron.xml)

The cron.xml for our application will contain only one Cron Job. And here we specify the Servlet URL along with the schedule. Notice that I have chosen to execute this Cron job every 2 minutes. But you are free to experiment if you like with different Schedule Formats. This files needs to be created in the WEB-INF folder of your project.

<?xml version="1.0" encoding="UTF-8"?>
<cronentries>
 <cron>
 <url>/cron/gaejcronjob</url>
 <description>GAEJExperiments Cron Job that simply announces that it got invoked.</description>
 <schedule>every 2 minutes</schedule>
 </cron>
</cronentries>

Deploy the Application

To deploy the application, follow these steps (they should be familiar to you now. I am assuming that you already have the Application ID with you):

1. Click on the Deploy Icon in the Toolbar.
2. In the Deploy dialog, provide your Email and Password. Do not click on Deploy button yet.
3. Click on the App Engine Project settings link. This will lead you to a dialog, where you need to enter your Application ID [For e.g. my Application Identifier gaejexperiments]
4. Click on OK. You will be lead back to the previous screen, where you can click on the Deploy button. This will start deploying your application to the GAEJ cloud. You should see several messages in the Console window as the application is being deployed.
5. Finally, you should see the message “Deployment completed successfully”.

We can now check if the Google App Engine got our Cron Job correctly configured and verify if it is getting executed at the schedule that we have configured it to.

Monitoring the Cron Job

You can use the App Engine console to verify if your Cron Job is executing well or not. To do that, perform the following steps:

1. Go to http://appengine.google.com and log in with your account.
2. You will see a list of applications registered. Click on the application that you just deployed. In my case, it is gaejexperiments.
3. When you click on a particular application, you will be taken to the Dashboard for that application, which contains a wealth of information around the requests, quotas, logs, versions, etc.
4. Verify that the Cron Jobs that you specified in the cron.xml have been configured successfully for the application by clicking Cron Jobs, visible under Main. For our application that we deployed, here is the screen shot from the App Engine console:

You will notice that the Cron Job has not yet run as the console indicates. Every time that the job is executed, this column is updated with the last date time stamp that the Job executed along with its status. Since we have configured our Job to run every 2 minutes, I waited for 2 minutes and then the job executed itself and when I refreshed the Cron Jobs page, the status was updated as shown below:

You can also click on the Logs link. This will display the application log. And all your application log statements that you code using the Logger class can be visible here. By default, the severity level is set at ERROR and we can change that to INFO and you should be able your log statements that had the log level of INFO. This was the log level at which we had logged the statement in our Java Servlet (Cron Job). Shown below is a screen shot of the log when the Cron Job was fired once.

Conclusion

This concludes Episode 9 of this series in which you learn how to schedule tasks in your Google App Engine applications. These background tasks that can be scheduled at a certain time and which are executed by the Cron Service are an indispensable part of several web applications that are deployed today. If you ever wish to do repeated tasks in your application without any user intervention like sending emails, crawling web sites, taking database backups, etc, then writing a Cron Job and scheduling it for execution is a key feature that you can utilize while deploying your application to Google App Engine.

There is a lot more to Cron Jobs and I suggest to read up the documentation.

Till the next episode, Happy Scheduling!

STOP PRESS – 17 Nov 2009  – updated with latest code which works against both 10g and 11g databases

 I am attaching scripts which I wrote a while ago to automatically pick any sql_ids reported in the latest ADDM and then run sql_advisor to report on any tuning advice. I am not suggesting that the information they provide is not available from EM or indeed every task reported needs resolving but it can be a good heads-up on a system you don’t know very well.

These are enabled every hour (can be less depending upon your snapshot interval) and they create a daily file which can be easily reviewed.

I find the real benefit is not on production databases but on dev and test databases that are being used for development prior to production implementation. This is for two reasons, firstly I hope that the team has a good handle on what is happening in production and are aware of issues and secondly we are most likely  to be able to add most value and benefit in development environments before the code is made live.

A couple of ‘issuettes’. The output from the ADDM report is different between 10g and 11g so I have amended the awk file to cater for both versions. I have been having an ongoing problem with tghe sql_advisor tuning task timing out on some systems and consequently leaving the task created for the next run. I have therefore amended the loop to drop the task at several points which looks untidy in the output file bit does seem to resolve the problem. 

I hoped to attach a zip file containing 4 scripts but cannot see how to do it without a plug-in which is a problem on my works PC. so in the meantime I have pasted the code of each of 4 files.

tuning_recommendations.ksh which is the controlling script

#! /bin/ksh
# loop though the file produced from get_addm_report.sql and put the gathered sql-ids into a flat file
# awk the file to get just the SQL_ID
# for each sql_id create a task, execute that task, run the report and then delete the task
#
# The delete tuning task job is run an additional twice because if the tuning task times out then it does not clean up properly
# Better to see a few failures in this job that not run the sql_tuning_advisor at all.
#if [ -d /home/oracle/logs ]
then
   rm  /home/oracle/logs/tmp*.log
   else
   mkdir /home/oracle/logs
   exit
fi
if [ $# -ne 1 ]
then
    echo "No ORACLE SID  - exiting"
    exit
fi
# execute ORACLE's .profile
#
#. ~/.profile
unset ORAENV_ASK
#
# set up environment variables.
#

ORACLE_SID=$1
. /usr/local/bin/oraenv ${ORACLE_SID}
export ORACLE_HOME=`cat /etc/oratab | grep $ORACLE_SID | awk -F: '{print $2 }`
export PATH=$ORACLE_HOME/bin:$PATH
export ORAENV_ASK=NO
today=`date +%d-%b-%Y`; export today
LOGDIR=$HOME/logs
LOGFILE=$LOGDIR/get_addm_${today}.log
REPORTFILE=$LOGDIR/sql_advisor_report_${ORACLE_SID}_${today}.log

#
#
sqlplus -s /nolog  <<SQLEND
connect / as sysdba
     spool $LOGDIR/tmp_${ORACLE_SID}_1.log
     @/shared/oracle/performance/get_addm_report.sql
     spool off
     exit
SQLEND

<p>&nbsp;</p>

cat $LOGDIR/tmp_${ORACLE_SID}_1.log|awk -f /shared/oracle/performance/tuning_recommendations.awk |awk '!a[$0]++' > $LOGDIR/tmp_${ORACLE_SID}_2.log
cat  $LOGDIR/tmp_${ORACLE_SID}_2.log | awk '$0!~/^$/ {print $0}' > $LOGDIR/tmp_${ORACLE_SID}_3.log

for PLAN in  `cat $LOGDIR/tmp_${ORACLE_SID}_3.log`
do
sqlplus -s /nolog  <<SQLEND >> $REPORTFILE
connect / as sysdba
        begin
        DBMS_SQLTUNE.drop_tuning_task('test_task1');
        end;
        /
     SELECT status FROM USER_ADVISOR_TASKS WHERE task_name = 'test_task1';
     @/shared/oracle/performance/sql_advisor.sql $PLAN
     exit
SQLEND
done

# tidy up the report file
# tidy up reports > 14 days old
find  $LOGDIR -name "sql_advisor_repor*.log" -mtime +14 -print -exec rm -f {} \;

get_addm_report.sql which gets each task from the last snapshot from dba_advisor_tasks

set long  10000000
set pagesize 50000
column get_clob format a80

select dbms_advisor.get_task_report (task_name) as ADDM_report
from dba_advisor_tasks
where task_id = (
        select max(t. task_id)
        from dba_advisor_tasks t, dba_advisor_log l
        where t.task_id = l.task_id
        and t.advisor_name = 'ADDM'
        and l.status = 'COMPLETED');

tuning_recommendations.awk is a short awk script used to process the output from get_addm_report.sql

BEGIN{
#start at the first line
#OUTFILE="$HOME/logs/outfile.log"
}
{
        {
                if (($1=="RATIONALE:") && ($2=="SQL")) #10G ADDM format
                {
                        F1=$6
                }
                if (($1=="Run") && ($2=="SQL") && ($3=="Tuning") && ($4=="Advisor") && ($7=="SQL") && ($10=="SQL_ID")) #11G ADDM format
                {
                        F1=$11
                }

        }
VAR1=substr(F1,2,13)
print VAR1
}
END{
}

sql_advisor.sql runs the sql_advisor package against each task found.

DECLARE
my_task_name   VARCHAR2 (30);
my_sqltext     CLOB;
my_sqlid        varchar2(30);

BEGIN
my_sqlid := '&1';
my_task_name := dbms_sqltune.create_tuning_task (sql_id=> my_sqlid,
       scope         => 'COMPREHENSIVE',
       time_limit    => 300,
       task_name     => 'test_task1',
       description   => 'test_task1'
    );
END;
/

BEGIN
dbms_sqltune.execute_tuning_task (task_name => 'test_task1');
END;
/

SELECT status FROM USER_ADVISOR_TASKS WHERE task_name = 'test_task1';
SET LONG 10000
SET LONGCHUNKSIZE 10000
SET LINESIZE 100
set pages 60
SELECT DBMS_SQLTUNE.REPORT_TUNING_TASK( 'test_task1')
FROM DUAL;
begin
DBMS_SQLTUNE.drop_tuning_task('test_task1');
end;
/

We have a read only NFS mounted disk available on all database servers and the files are placed in there and initiated by a cron entry for each SID on an hourly basis
40 * * * * /shared/oracle/performance/tuning_recommendations.ksh SID >/dev/null 2>&1

Output is created in a folder $HOME/logs and 14 days worth of reports are kept.

A sample output report (only one task shown but certainly on this Peoplesoft database it would show many tasks)

DBMS_SQLTUNE.REPORT_TUNING_TASK('TEST_TASK1')
----------------------------------------------------------------------------------------------------
GENERAL INFORMATION SECTION
-------------------------------------------------------------------------------
Tuning Task Name                  : test_task1
Tuning Task Owner                 : SYS
Scope                             : COMPREHENSIVE
Time Limit(seconds)               : 60
Completion Status                 : COMPLETED
Started at                        : 11/12/2009 07:43:33
Completed at                      : 11/12/2009 07:44:16
Number of Statistic Findings      : 1
Number of Index Findings          : 1

-------------------------------------------------------------------------------
Schema Name: SYSADM
SQL ID     : cy3fmjha2sjnr
SQL Text   : SELECT M.EMPLID, M.EMPL_RCD, M.SCH_PRIM_ALT_IND,
             TO_CHAR(M.DUR,'YYYY-MM-DD'), M.SEQ_NO, M.CHNG_PRIMARY,
             M.SCHEDULE_GRP, M.SETID, M.WRKDAY_ID, M.SHIFT_ID, M.SCHED_HRS,
             M.SCH_CONFIG1, M.SCH_CONFIG2, M.SCH_CONFIG3, M.SCH_CONFIG4,
             TO_CHAR(M.START_DTTM,'YYYY-MM-DD-HH24.MI.SS."000000"'),
             TO_CHAR(M.END_DTTM,'YYYY-MM-DD-HH24.MI.SS."000000"'),
             M.SCHED_SOURCE, M.OFFDAY_IND, A.TIMEZONE, A.SCH_CATEGORY From
             PS_SCH_MNG_SCH_TBL M, PS_SCH_ADHOC_DTL A Where M.EMPLID = :1 and
             M.EMPL_RCD = :2 and M.SCH_PRIM_ALT_IND = :3 and M.DUR between
             TO_DATE(:4,'YYYY-MM-DD') and TO_DATE(:5,'YYYY-MM-DD') and
             A.EMPLID = M.EMPLID and A.EMPL_RCD = M.EMPL_RCD and
             A.SCH_PRIM_ALT_IND = M.SCH_PRIM_ALT_IND and A.DUR = M.DUR and
             A.SEQ_NO = M.SEQ_NO and A.SEQNUM = 1 Order By M.DUR Asc,
             M.SCHED_SOURCE Desc, M.SEQ_NO Desc

-------------------------------------------------------------------------------
FINDINGS SECTION (2 findings)
-------------------------------------------------------------------------------

1- Statistics Finding
---------------------
  Optimizer statistics for index "SYSADM"."PS_SCH_MNG_SCH_TBL" are stale.

  Recommendation
  --------------
  - Consider collecting optimizer statistics for this index.
    execute dbms_stats.gather_index_stats(ownname => 'SYSADM', indname =>
            'PS_SCH_MNG_SCH_TBL', estimate_percent =>
            DBMS_STATS.AUTO_SAMPLE_SIZE);

  Rationale
  ---------
    The optimizer requires up-to-date statistics for the index in order to
    select a good execution plan.

2- Index Finding (see explain plans section below)
--------------------------------------------------
  The execution plan of this statement can be improved by creating one or more
  indices.

  Recommendation (estimated benefit: 94.67%)
  ------------------------------------------

DBMS_SQLTUNE.REPORT_TUNING_TASK('TEST_TASK1')
----------------------------------------------------------------------------------------------------
  - Consider running the Access Advisor to improve the physical schema design
    or creating the recommended index.
    create index SYSADM.IDX$$_21C0F0001 on
    SYSADM.PS_SCH_ADHOC_DTL("EMPLID","SEQNUM","EMPL_RCD","SCH_PRIM_ALT_IND","DU
    R");

  - Consider running the Access Advisor to improve the physical schema design
    or creating the recommended index.
    create index SYSADM.IDX$$_21C0F0002 on
    SYSADM.PS_SCH_MNG_SCH_TBL("EMPLID","DUR");

  Rationale
  ---------
    Creating the recommended indices significantly improves the execution plan
    of this statement. However, it might be preferable to run "Access Advisor"
    using a representative SQL workload as opposed to a single statement. This
    will allow to get comprehensive index recommendations which takes into
    account index maintenance overhead and additional space consumption.

-------------------------------------------------------------------------------
EXPLAIN PLANS SECTION
-------------------------------------------------------------------------------

1- Original
-----------
Plan hash value: 2070933151

----------------------------------------------------------------------------------------------------
------------------------
| Id  | Operation                             | Name               | Rows  | Bytes | Cost (%CPU)| Ti
me     | Pstart| Pstop |
----------------------------------------------------------------------------------------------------
------------------------
|   0 | SELECT STATEMENT                      |                    |     1 |   103 |   387   (1)| 00
:00:01 |       |       |
|*  1 |  FILTER                               |                    |       |       |            |
       |       |       |
|   2 |   SORT ORDER BY                       |                    |     1 |   103 |   387   (1)| 00
:00:01 |       |       |
|   3 |    NESTED LOOPS                       |                    |     1 |   103 |   386   (1)| 00
:00:01 |       |       |
|   4 |     PARTITION RANGE ITERATOR          |                    |    10 |   350 |   371   (1)| 00
:00:01 |   KEY |   KEY |
|   5 |      TABLE ACCESS BY LOCAL INDEX ROWID| PS_SCH_ADHOC_DTL   |    10 |   350 |   371   (1)| 00
:00:01 |   KEY |   KEY |
|*  6 |       INDEX RANGE SCAN                | PS_SCH_ADHOC_DTL   |    10 |       |   369   (1)| 00
:00:01 |   KEY |   KEY |
|   7 |     PARTITION RANGE ITERATOR          |                    |     1 |    68 |     2   (0)| 00
:00:01 |   KEY |   KEY |
|   8 |      TABLE ACCESS BY LOCAL INDEX ROWID| PS_SCH_MNG_SCH_TBL |     1 |    68 |     2   (0)| 00
:00:01 |   KEY |   KEY |
|*  9 |       INDEX UNIQUE SCAN               | PS_SCH_MNG_SCH_TBL |     1 |       |     1   (0)| 00
:00:01 |   KEY |   KEY |
----------------------------------------------------------------------------------------------------
------------------------

Predicate Information (identified by operation id):

DBMS_SQLTUNE.REPORT_TUNING_TASK('TEST_TASK1')
----------------------------------------------------------------------------------------------------
---------------------------------------------------

   1 - filter(TO_DATE(:4,'YYYY-MM-DD')<=TO_DATE(:5,'YYYY-MM-DD'))
   6 - access("A"."EMPLID"=:1 AND "A"."EMPL_RCD"=TO_NUMBER(:2) AND "A"."SCH_PRIM_ALT_IND"=:3 AND
              "A"."DUR">=TO_DATE(:4,'YYYY-MM-DD') AND "A"."SEQNUM"=1 AND "A"."DUR"<=TO_DATE(:5,'YYYY
-MM-DD'))
       filter("A"."SEQNUM"=1)
   9 - access("M"."EMPLID"=:1 AND "M"."EMPL_RCD"=TO_NUMBER(:2) AND "M"."SCH_PRIM_ALT_IND"=:3 AND
              "A"."DUR"="M"."DUR" AND "A"."SEQ_NO"="M"."SEQ_NO")
       filter("M"."DUR">=TO_DATE(:4,'YYYY-MM-DD') AND "M"."DUR"<=TO_DATE(:5,'YYYY-MM-DD'))

2- Using New Indices
--------------------
Plan hash value: 1209469329

----------------------------------------------------------------------------------------------------
------------------------
| Id  | Operation                             | Name               | Rows  | Bytes | Cost (%CPU)| Ti
me     | Pstart| Pstop |
----------------------------------------------------------------------------------------------------
------------------------
|   0 | SELECT STATEMENT                      |                    |     1 |   103 |    21  (10)| 00
:00:01 |       |       |
|*  1 |  FILTER                               |                    |       |       |            |
       |       |       |
|   2 |   SORT ORDER BY                       |                    |     1 |   103 |    21  (10)| 00
:00:01 |       |       |
|*  3 |    HASH JOIN                          |                    |     1 |   103 |    20   (5)| 00
:00:01 |       |       |
|   4 |     TABLE ACCESS BY GLOBAL INDEX ROWID| PS_SCH_ADHOC_DTL   |    10 |   350 |    10   (0)| 00
:00:01 | ROWID | ROWID |
|*  5 |      INDEX RANGE SCAN                 | IDX$$_21C0F0001    |    10 |       |     4   (0)| 00
:00:01 |       |       |
|*  6 |     TABLE ACCESS BY GLOBAL INDEX ROWID| PS_SCH_MNG_SCH_TBL |    13 |   884 |     9   (0)| 00
:00:01 | ROWID | ROWID |
|*  7 |      INDEX RANGE SCAN                 | IDX$$_21C0F0002    |    13 |       |     3   (0)| 00
:00:01 |       |       |
----------------------------------------------------------------------------------------------------
------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter(TO_DATE(:4,'YYYY-MM-DD')<=TO_DATE(:5,'YYYY-MM-DD'))
   3 - access("A"."EMPLID"="M"."EMPLID" AND "A"."EMPL_RCD"="M"."EMPL_RCD" AND
              "A"."SCH_PRIM_ALT_IND"="M"."SCH_PRIM_ALT_IND" AND "A"."DUR"="M"."DUR" AND
              SYS_OP_DESCEND("A"."DUR")=SYS_OP_DESCEND("M"."DUR") AND "A"."SEQ_NO"="M"."SEQ_NO")
   5 - access("A"."EMPLID"=:1 AND "A"."SEQNUM"=1 AND "A"."EMPL_RCD"=TO_NUMBER(:2) AND "A"."SCH_PRIM_
ALT_IND"=:3 AND
              "A"."DUR">=TO_DATE(:4,'YYYY-MM-DD') AND "A"."DUR"<=TO_DATE(:5,'YYYY-MM-DD'))
   6 - filter("M"."SCH_PRIM_ALT_IND"=:3 AND "M"."EMPL_RCD"=TO_NUMBER(:2))
   7 - access("M"."EMPLID"=:1 AND "M"."DUR">=TO_DATE(:4,'YYYY-MM-DD') AND "M"."DUR"<=TO_DATE(:5,'YYY
Y-MM-DD'))

-------------------------------------------------------------------------------

PL/SQL procedure successfully completed.

The routine above works well but I am happy to consider any changes or improvements.

PS If anybody knows how to use a code tag and not have those horrible green wraparound marks please let me know

Cron: sắp xếp các sự kiện thành một hàng đợi và thực hiện vào một khoảng thời gian.

Il titolo sarebbe dovuto essere molto piu’ lungo, una cosa del tipo: “usare uno script in bash per scaricare i file .torrent da un indirizzo RSS per poi farli scaricare da aria2c automaticamente grazie a crontab“. Tutto e’ cominciato quando ho trovato questo script in bash (scritto da di voRia), vedendolo mi sono detto: “perche’ fermarsi qui?” Ma e’ d’obbligo una premessa, scaricare le serie televisive e’ un reato, quindi non fatelo, ho usato lo script solo a titolo di esempio bla bla bla, ma chi ci crede. Allora continuiamo.

Prima di tutto prendete quel file e personalizzatelo. Per farlo dovete andare sul sito ezRSS.it e copiare il link dei feed RSS delle vostre serie preferite. Ad esempio Monk, Dr. House e Warehouse 13. Poi dobbiamo decidere dove scaricare i file .torrent e con quale programma scaricare i torrent (aria2c nell’esempio, ma poteva benissimo essere anche transmissioncli). Ora possiamo personalizzare lo script:

---8<---
#!/bin/bash

TORRENTDIRECTORY="/home/luca/downloads/torrents/torrentfiles/"
RSSFILE=/tmp/rssfile

URL_MONK="http://www.ezrss.it/search/index.php?show_name=Monk&date=&quality=HDTV&quality_exact=true&release_group=&mode=rss"
URL_WAREHOUSE13="http://www.ezrss.it/search/index.php?show_name=Warehouse+13&date=&quality=HDTV&quality_exact=true&release_group=&mode=rss"
URL_DRHOUSE="http://www.ezrss.it/search/index.php?show_name=House&show_name_exact=true&date=&quality=HDTV&quality_exact=true&release_group=&mode=rss"

RSSLINKS=`echo $URL_MONK $URL_WAREHOUSE13 $URL_DRHOUSE`

# Fa in modo che la la directory dove verranno scaricati i torrent esista
mkdir -p $TORRENTDIRECTORY

# Scarica gli RSS
wget $RSSLINKS -O $RSSFILE -o /dev/null

# Recupera tutti i link .torrent dal file RSS
LINKS=`cat $RSSFILE | grep "<link>" | grep .torrent`
LINKS=`echo $LINKS | sed "s:<link>::g"`
LINKS=`echo $LINKS | sed "s:</link>::g"`

# Recupera tutte le date dal file RSS
DATES=`cat $RSSFILE | grep "<pubDate>"`
DATES=`echo $DATES | sed "s:<pubDate>::g"`
DATES=`echo $DATES | sed "s:</pubDate>::g"`

# Conta il numero di torrent recuperati
num=0
for LINK in $LINKS; do
	let "num += 1"
done

# Recupera solo i dati che ci interessano della data,
# cioè giorno, mese e anno (campi 2, 3 e 4).
DAYS=""
MONTHS=""
YEARS=""
counter=0
for DATE in $DATES; do
	let "counter += 1"
	if [ $counter -eq 2 ]; then
		DAYS=`echo $DAYS $DATE`
	fi
	if [ $counter -eq 3 ]; then
		MONTHS=`echo $MONTHS $DATE`
	fi
	if [ $counter -eq 4 ]; then
		YEARS=`echo $YEARS $DATE`
	fi
	if [ $counter -eq 6 ]; then
		counter=0
	fi
done

# Ricostruisce tutte le date nel formato finale che ci interessa.
# Esempio: 3 novembre 2009 -> 03112009
DATES=""
for i in `seq $num`; do
	DAY=`echo $DAYS | cut -d' ' -f $i`
	case `echo $MONTHS | cut -d' ' -f $i` in
		Jan)
			MONTH=01
			;;
		Feb)
			MONTH=02
			;;
		Mar)
			MONTH=03
			;;
		Apr)
			MONTH=04
			;;
		May)
			MONTH=05
			;;
		Jun)
			MONTH=06
			;;
		Jul)
			MONTH=07
			;;
		Aug)
			MONTH=08
			;;
		Sep)
			MONTH=09
			;;
		Oct)
			MONTH=10
			;;
		Nov)
			MONTH=11
			;;
		Dec)
			MONTH=12
			;;
	esac
	YEAR=`echo $YEARS | cut -d' ' -f $i`
	DATES=$DATES$DAY$MONTH$YEAR`echo " "`
done

# Il file RSS scaricato non ci serve più
rm $RSSFILE

# A questo punto abbiamo:
# - $LINKS : lista ordinata di tutti i file .torrent
# - $DATES : lista ordinata di tutte le date

# Scarica i .torrent di ieri
cd $TORRENTDIRECTORY
for i in `seq $num`; do
	if [ `date +%d%m%Y -d "yesterday"` == `echo $DATES | cut -d' ' -f $i` ]; then
		TORRENT=`echo $LINKS | cut -d' ' -f $i`
		wget -c "$TORRENT" -o /dev/null
	fi
done

# Facciamo scaricare i file torrent con Aria2c
aria2c *.torrent

---8<---

Copiamo e incolliamo in un file vuoto rinominato rsstorrentserie, mettiamolo dove piu’ ci aggrada (ad esempio in /home/UTENTE/script/) e rendiamolo eseguibile:
# chmod a+x rsstorrentserie
A questo punto non ci resta che programmare lo script con crontab in modo che ogni settimana venga avviato.

Per far questo dobbiamo sapere come usare cron. Per questo ci sono tante guide, ad esempio questa guida sull’utilizzo del servizio di scheduling Cron.

Dobbiamo far si che alle 20:30 di ogni domenica venga eseguito il nostro script. Possiamo farlo in vari modi:

1) Creiamo un file nella directory /etc/cron.d/ col nome che preferiamo e con questo contenuto:

---8<---
# /etc/cron.d/nomechepreferite

SHELL=/bin/sh
PATH=/home/UTENTE/script

30 20 * * 0   UTENTE	/home/UTENTE/script/rsstorrentserie
---8<---

in questo modo alle ore 20:30 di ogni domenica verra’ avviato il nostro script (solo se il computer e’ acceso).

2) L’altro metodo e’ quello di scrivere il comando:
$ crontab -e
scrivere tutto il necessario nell’editor che si aprira’ e dopo uscire dall’editor. Per vedere se abbiamo scritto tutto giusto possiamo scrivere questo comando:
$ crontab -l
se dovessimo aver sbagliato o comunque per cancellare i compiti usiamo questo comando:
$ crontab -r
per cancellare solo il compito visto in questo esempio:
$ crontab -r filecompitoquestoesempio

3) Oppure possiamo scrivere il contenuto che abbiamo visto prima:

---8<---
# /etc/cron.d/nomechepreferite

SHELL=/bin/sh
PATH=/home/UTENTE/script

30 20 * * 0   UTENTE	/home/UTENTE/script/rsstorrentserie
---8<---

in un file dove vogliamo (ad esempio /home/UTENTE/dovevogliamo/) e darlo in pasto a cron con questo comando:
$ crontab /home/UTENTE/dovevogliamo/file
sara’ lui che si occupera’ del resto.

In realta’ ci sono anche altri modi, come ad esempio scrivere direttamente nel file /etc/crontab, ma se dovessi proprio scegliere preferisco il terzo metodo (crontab file). Adesso aspettiamo le 20:30 di domenica per vedere se funziona tutto.

Pensandoci bene, lo script cosi’ com’e’ scarica i torrent nuovi, con la data del giorno prima, sarebbe dunque piu’ corretto nel crontab inserire al posto di:

---8<---
30 20 * * 0   UTENTE	/home/UTENTE/script/rsstorrentserie
---8<---

questo:

---8<---
30 14 * * *   UTENTE	/home/UTENTE/script/rsstorrentserie
---8<---

in modo che lo script venga eseguito alle 14:30 di ogni giorno. Se sappiamo la data esatta dell’uscita dei torrent, ad esempio il mercoledi’ e il venerdi’, possiamo anche scrivere:

---8<---
30 14 * * 4,6   UTENTE	/home/UTENTE/script/rsstorrentserie
---8<---

in questo modo lo script verra’ eseguito alle 14:30 il giovedi’ e il sabato.

Per le varie possibilita’ vedete voi, anche modificando lo script in modo che scarichi tutti i torrent non del giorno prima ma di quella settimana, cosi’ da avviare lo script solo un giorno la settimana.

[^] torna su | post<li> | 

Many people are struggling with how to deal with their backups. Normally backups are a problem handled by some administrator who copies a whole bunch of stuff onto a tape cassette. Often without knowing how, if even possible to restore everything from the data on the tape cassette.

I approached this at a different angle.

As developers we needed a staging environment for the application we are developing. Using the live servers is not okay in my opinion. So I found an old P4 box with 1GB ram. Slapped in a new HDD for the databases and started setting this up as a development server. Of course, porting the code to make it mobile enough to move it to this server was one thing, which is another story. But getting concurrent versions of the databases onto this server was were the backups came into play.

Using the development server as a test case for the backups, I had everything I needed to build a true case where I could assure that each and every backup taken would work. Each backup is restored to the development server and as we developers use the development server, we see if some data goes terribly wrong. Of course, this does not protect us from the scenario where some data is malformed in a uniformed way, producing false positives. However, all data which goes into our system is backed up separately, so everything can be rebuilt if needed. This data is checked via md5 hashes, so no malformation is possible there.

So, the backups are taken to a backup server, custom built for the purpose. This server is an office version. We wanted an out-of-the-server-park backup, so we decided to put a server at our office. The box is custom built by myself and based on a Chieftec chassis with an Intel motherboard and Intel processor. I used a highpoint rocketraid 3210 as a RAID controller. I built a RAID5 from four Western Digital 1TB hard drives. We also have two spares in the server, so in case we need to rebuild the RAID we do not have to wait for a delivery.

A word or two on security.

When doing cross server backup transfers, you must always make sure you know your security priorities. In my case I trust the backup server far more than the live servers. This is often how the case should be in my opinion. The backup servers are exposed to no one but the live servers and the developers. and the live servers are exposed to the whole world. Thus, the more likely first target of an attack would be the live servers. If the backup servers trust the live servers, and the live servers are compromised, the backup server will be compromised as well. This is why we build the backup scripts on the backup server and make them fetch the data from the live servers, rather than having the live servers push the data to the backup server.

The backup scripts are in our case built in php, so all developers at this  company can understand them. I would rather have built them in straight bash or perhaps python, but the advantage of more people being able to understand all code is far greater than having used “that cool programming language”. Of course the php executes complex shell commands to do most of the actual work, but the flow of the program is entirely php.

So, how do you set all this up?

The way to set up these kind of scripts are with ssh certificates, crontab and some basic php code.

First you need to set up a user on the live servers who will have only the privileges of reading the files/databases which needs to be backed up. I’m calling this user ‘backup’ for easy reference.
the adduser command is slightly different in many distros, so read up on it if you are unsure.

man adduser

Secondly you need to give the backup user on your live server the public key of the backup user on your backup server. So log on to your backup server as your backup user and type:

ssh-keygen -t rsa

a file “id_rsa.pub” should be generated in the .ssh directory in your home directory (~/.ssh/id_rsa.pub). This file contains one(1) line and this line is this user at this machines public key. It identifies this user at this machine. What you need to do now is to transfer this line into the live servers’ authorized keys file. (~/.ssh/authorized_keys). This file may not even exist on the live servers, but if it does, make sure only to add your public key line to the end of this file. Do not overwrite. The magical unix command for doing this would be:

cat ~/.ssh/id_rsa.pub | ssh backup@your.liveserver “cat >> ~/.ssh/authorized_keys”

of course, you should double check these kind of things manually and not rely on a copy-pasted command from blogs like mine. The command above does give you a hint on how the backups are transferred though.
After you have put the backup user of the backup servers public key into the authorized keys file of the backup user on the live server, you should now be able to log in from the backup server as the backup user on the live server as the backup user, without being prompted for a password. If this is not the case, you’ve done something wrong. Start from the beginning.

So, now we need to start writing the actual script which controls the flow of the backup process. I will now write an explanation which can be applied into any kind of programming language.

First thing we need to do is to get the information on what databases we need to back up from the server. We do this with an easy shell command executed from within the script, and then parsing the output it gives us. Why do we not use a local mysql client implementation to query the database directly and get a mysql resultset? Simple. We do not want to expose the live mysql to the outside world. So what do is we issue the following command in a shell controlled by the script (so we can get the output into our code and use it):

ssh backup@your.liveserver mysqlshow

This will initiate a new ssh connection to your live server, and the command mysqlshow is sent over that connection, just as if you would have logged in and done it yourself. All output from mysql will be returned and will end up in your script.
Once you have gotten this down you will have to parse what mysql throws at you. This should be a no brainer. I use this regular expression /[\w]+/ because all we really need to do is remove all spaces and pipes. Of course, this regular expression must match all your databases you need to backup. Maybe you only have one database to back up, in which case, you do not need to do this step really.

Next thing in the script is to, for each database we want to backup, get the dump from the database. But how do we do this without actually writing everything to disk as dump files? Easy. This command may seem complex, but I will walk you trough it step by step:

ssh backup@your.liveserver “mysqldump databasename | gzip -c” > /your_backup_location/databasename_date.mysqldump.gz

ok. this may look scary for some of you. If you are not familiar with the mysqldump command, what it does is it outputs in plaintext a full recreation script for the database in question. So we initiate an ssh connection and tell the server to start outputting the whole database. Then we take all which it outputs and hand it over to gzip, which zips the output and with the -c parameter it just passes the zipped output on. All of this ends up on your side of the ssh connection, where you in turn tell it to go into the file /your_backup_location/databasename_date.mysqldump.gz
All data is zipped and done when it gets to your side of the connection.
Restoring from this file is also easy. The following command can be used for that:

cat /your_backup_location/databasename_date.mysqldump.gz | ssh backup@your.liveserver “gunzip -c | mysql databasename”

So, having the script done we need to put this into a crontab on the backup server. Note that nothing except for the authorized_keys have been changed on the live server.
crontab -e
lets you edit your crontab. Here you need to write a crontab line. The crontab may be empty, in which case it is hard to remember which order everything should be put, so here is a reference:

min     hour     day_of_month     month      day_of_week      command to be executed

So if we want this script to be executed every evening at 23:42 except for on Sundays, because then the server does other heavy load things, we would write something like this:

42      23         *           *            1-6        /path/to/script

A better reference for crontab can be found here: http://www.adminschoice.com/docs/crontab.htm#Crontab%20file

ive been trying to get cron-apt to download and install packages. i was able to get it to update and download, but never to install, and i dont want to know how to do it anymore. really all you need to do is put an executable file in /etc/cron.daily/cronaptitude with

#!/bin/bash
aptitude update
aptitude -y safe-upgrade

that’s all i wanted, and its so much simpler than cron-apt. i know there’s a “safety” issue with automatically upgrading, but ive stopped looked at specific packages years ago when i upgraded and havent had problems. sometimes X will break or the kernel will break, but this is not a problem. its easier to fix this when it happens once every couple of years than it is to not have cron upgrading automatically and then every week or 2 having a giant upgrade.

another thing which cropped up was that if i put that script in /etc/cron.daily then it works, but if i have root do crontab -e then it complains about paths. then in root’s crontab you have to add the line

PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:$PATH

Escavando a pilha de asneiras que a sociedade joga sobre os mortos, podemos encontrar bastante coisa útil. Entre o montante encontra-se discursos vazios, ideologias baratas, elogios desnecessários. Ao mesmo tempo, por meio de uma análise minuciosa, é possível resgatar o estudo, o esforço e a dedicação.

Em uma recente edição da revista Bravo, diferentes fotógrafos comentaram sobre a técnica e o estilo de Henry Cartier-Bresson. Os elogios repetiam-se pelas colunas da reportagem. Ou os entrevistados tinham pouquíssima criatividade e um vocabulário à la jardim de infância ou realmente fracas definições como “decisivo” e “incomparável” encaixam-se por unânimidade ao fotógrafo francês.

Bresson, mais do que um exímio fotojornalista, foi um homem que desde pequeno possuía uma paixão. Do dia em que ganhou uma máquina fotográfica Box Brownie à sua participação na Segunda Guerra Mundial já há uma experiência de vida inigualável. Sua carreira nas revistas Life e Vogue com certeza fortaleceram sua perspectiva e técnica.

No entanto, quantos não devem ter sido os filmes queimados ou as fotos descartadas pelos inúmeros editores ao longo da carreira do francês? Bresson, como todos, era um ser humano. Convivia com altos e baixos.  Dedicou-se diariamente para obter excelência. Contudo, não significa que, desde os tempos da primeira 35mm, suas imagens já tinham seu ponto de vista especialíssimo.

What’s better than BBC’s iPlayer? get_iplayer of course, a Perl script that rips programmes to your local machine.

I now have get_iplayer set up with cron to download TV programmes that I’m interested in (have a guess from the list below):

0 3 * * *	cd Desktop && get_iplayer -l --nopurge --get Beatle
30 3 * * * 	cd Desktop && get_iplayer -l --nopurge --get Brooker
0 4 * * * 	cd Desktop && get_iplayer -l --nopurge --get Japan
30 4 * * *      cd Desktop && get_iplayer -l --nopurge --get Horizon
0 5 * * *       cd Desktop && get_iplayer -l --nopurge --get Buzzcocks

Update

Everyone points out in the comments that get_iplayer has a --pvr option that makes this even easier.

Setting up cron in Ubuntu is simple enough as described in the Ubuntu wiki. But what they don’t mention is that by default cron uses /bin/sh for its SHELL env variable. That may cause a problem if you try to set up a bash script in cron. To prevent that from happening, you need to define the SHELL variable for your user crontab to point to /bin/bash.

In the console type:

crontab -e

Add the following line at the top:

SHELL=/bin/bash

Your crontab should look something like this:

SHELL=/bin/bash
# m h  dom mon dow   command
*/5 * * * * /usr/local/bin/my_bash_script

After tweaking my nas to be able to backup my Vista machines to it, I started wondering about its power consumption and lifetime since its disk never seems to spin down. Of course I could get off my chair and turn the thing off when I’m not using it, but that kinda kills the adea of a network share, doesn’t it ?
Since hdparm doesn’t work (it’s a sata disk) first thing I thought of was to try to spin down the disk after a certain idle time using dsparm. No luck there. As a Windows kinda guy, I was unable to get any pre-compiled of self-compiled version of sdparm working.

To make a long story short, I finally rested my case by powering off the device at night using a cron job. Not exactly what I had in mind, but it sure meets the purpose of saving on my electricity bills. Note that, for some reason, poweroff reboots the device, and halt powers it off…

If you want to do so on you Lacie, here you go:

• You need shell access, I use telnet. If you don’t: check here
• First, make a copy of your crontab entries (there should be one entry from you mediaserver).

Crontab –l > tempcron

• Now edit tempcron :

vi tempcron

• Press ESC, then i to start editing
• Add a line like the one below to shut down at 2:30 AM:

30 2 * * * /sbin/halt

• Press ESC, then :, then wq, then enter to save and close the editor
• Now apply to crontab:

crontab tempcron

• Check your conjobs:

crontab –l

• Delete the tempcron file:

rm tempcron

That’s it! Now your nas will poweroff at night automatically.

“Se ha hablado del ateísmo militante de Saramago. En efecto, sus polémicas no se dirigen contra Dios: una vez admitido que su “eternidad es sólo la de un eterno no ser”, Saramago podría haberse quedado tranquilo. Su hastío se dirige contra las religiones […] Saramago ha azotado a las religiones como germen de conflictos: “Las religiones, todas sin excepción, no servirán nunca para acercar y reconciliar a los hombres; todo lo contrario, han sido y siguen siendo causa de sufrimientos inenarrables, de matanzas, de una monstruosa violencia física y espiritual” ….

Umberto Eco,  prólogo a El Cuaderno , de José Saramago.

Fuente l  Radiocable (inagotable)

 Además, como se ha observado ya en el contexto de la Câd Goddeu, las judias se utilizaban en los tiempos clásicos como talismán homeopático contra las brujas y los espíritus: se ponía una judia en la boca y se la escupía al visitante; y en las fiestas romanas de las Lemurias cada cabeza de familia arrojaba judias negras para los Lemures, o espectros, mientras decía: “Con éstas me redimo a mí mismo y a mi familia”.

Fuente original

The White Golddess- A Historical Grammar of Poetic Mytch. Robert Graves

© Robert Graves, 1948

© Ed. cast.: Alianza Editorial S.A. Madrid.1983

Robert Graves cita a Ovidio  identificando a Cardea ,  en su obra “La Diosa Blanca”:

“Su poder consiste en abrir lo que está cerrado y en cerrar lo que está abierto.”

 A veces nada…

A Lu… “forjadora de utopías”…

With Linux, when issuing command like crontab-e   or    crontab -l,  in some case it is beneficial for us if we had known their location.

well I tell just directly, they are located in /var/spool/cron  

those “crontab” files in /etc/cron* aren’t what I was looking for (it is not the same file as crontab -e)

In my case,  my  environment OS is under a VM machine and somehow, I don’t know why yet, each time I issued crontab -l   or crontab -e the CPU usage will go to 100% in 3 minutes right from a fresh boot.  I’ve tried to vi the file, but cpu becoming gradually unresponsive.. also,  I’ve tried to replace the file via FTP.  It still can’t be changed altough the file permission is 600 (I’m as root). 

So,

1. I cat the file (the filename is the same as the user who created the file)

2. make a new file named root2, which I changed the content according to my needs

3. rm -rf root

4. mv root2 root

5. chmod 600 root

Hope this post could be helpful under some circumstances..

Cron دایمونی (Daemonها مانند سرویس ها در سیستم عامل ویندوز است) است که برای زمان بندی کارها در گنو/لینوکس استفاده می شود. هر کاربر در گنو/لینوکس دارای یک فایل به نام crontab است که دایمون Cron برنامه هایی که در فایل های crontab قرار دارند را بر اساس زمان بندی آن ها اجرا می کند.

برای ایجاد فایل crontab به راهنمای ویکی در این جا مراجعه کنید.

برنامه هایی که شما می خواهید اجرا کنید به دو صورت هستند:

1. برنامه هایی که دارای محیط گرافیکی کاربر هستند (GUI) و نیاز به تعامل با سرویس دهنده پنجره X هستند مانند مرورگر Firefox
2. برنامه هایی که بدون GUI هستند که این برنامه ها خروجی و ورودی آن ها در پوسته خط فرمان است و برای اجرا شدن نیازی به تعامل با سرویس دهنده پنجره X ندارند. مانند برنامه ls یا GPG

برنامه هایی که در دسته دوم قرار می گیرند بدون هیچ مشکلی به وسیله Cron اجرا می گردند. اما برنامه های دستهٔ اول که دارای GUI هستند فقط با نوشتن دستور مورد نظر اجرا نخواهند شد. قبل از دستور باید به سرویس دهنده X بگویید که برنامه در کدام صفحه نمایش برای شما اجرا شود. برای این منظور قبل از دستور مورد نظر از env DISPLAY=:0 استفاده می کنیم. به عنوان مثال برای اجرای برنامه gedit در ساعت 10:25 هر روز صبح در فایل crontab دستور زیر را وارد می کنیم:

25 10 * * * env DISPLAY=:0 /usr/bin/gedit

DISPLAY=:0 به Cron می گوید که برنامه در صفحه جاری (desktop) اجرا شود.

و اگر دارای چندین صفحه نمایش هستید از دستور زیر استفاده می کنیم:

25 10 * * * env DISPLAY=:0.0 /usr/bin/gedit

DISPLAY=:0.0 به Cron می گوید که برنامه در صفحه نمایش اول و در صفحه جاری اجرا شود.

توجه: در اوبونتوی 9.10 (کارمیک) شما باید X ACL را برای localhost فعال کنید. برای این منظور از دستور زیر استفاده می کنیم:

xhost +local:

این دستور حتما باید قبل از اجرا شدن یک برنامه GUI به وسیله Cron اجرا شود. شما می توانید این دستور را در قسمت Startup Application قرار دهید تا هنگام بوت شدن سیستم اجرا شود.

=-=-=-=-=
Powered by Bilbo Blogger

What is Cron?

Cron enables users to schedule jobs (commands or shell scripts) to run automatically at a certain time or date. It is commonly used to perform system maintenance or administration, though its general purpose nature means that it can be used for other purposes, such as connecting to the Internet and downloading email.

Cron uses the crontab, a configuration file that specifies shell commands to run periodically on a given schedule.

Crontab has following options:

-l    list the crontab

-e    edit the crontab

-r    remove the crontab

The application “crontab” is used to create and edit cron jobs and the cron daemon checks for cronjobs a the top of every minute.

For example :

crontab -e

It opens the vi editor to enter the cron jobs.

It looks like

#   minute (0-59),
#   |   hour (0-23),
#   |   |   day of the month (1-31),
#   |   |   |   month of the year (1-12),
#   |   |   |   |   day of the week (0-6 with 0=Sunday).
#   |   |   |   |   |   commands

For Example:
55 10 8 11 * echo “This runs at 10:55 on 8th November”

To list all cron jobs:

crontab -l

To remove a cron job :

crontab -r

For alarm clock, A Command Line Mp3 player can be used here that is mpg321. you may use any mp3 player here but you have to specify what X display to play your player.

For Command Line Mp3 Player,

30  04  *   *   * mpg321 "/home/sriram/Music/Alarm1.mp3"

For Other Mp3 Player(Audacious):

30  04  *   *   * env DISPLAY=:0.0 audacious "/home/sriram/Music/Alarm1.mp3"

The asterik can be used (*) to satisfy all variables. I found some good alarm tracks at this site the were perfect for the task