Jun 15

坑爹的crontab #2 不指定

felix021 @ 2011-6-15 12:25 [IT » 操作系统] 评论(2) , 引用(0) , 阅读(12663) | Via 本站原创
我喜欢在自己的 $HOME 下面建立一个 bin ,然后添加到 $PATH 中,这样我可以方便地执行自己的程序:

$ mkdir ~/bin
$ vi .bashrc
export PATH=$PATH:~/bin

不过坑爹的 crontab 对 .bashrc 并不买账,通过

* * * * *  echo $PATH > ~/cronpath.txt

可以看出, crontab 执行命令时没有把环境变量给切过来。

$ cat ~/cronpath.txt
/usr/bin:/bin
Jun 14

坑爹的crontab 不指定

felix021 @ 2011-6-14 23:40 [IT » 操作系统] 评论(0) , 引用(0) , 阅读(3797) | Via 本站原创
#UPDATE: 并不是不能处理反引号,而是不能直接写%,需要转义。

某脚本x.sh,接受一个参数,比如20110517,用于处理20110517的日志。

处理前一天的日志,非常理所当然地使用如下命令
PATH_TO_SCRIPT/x.sh `date -d "-1 day" +%Y%m%d`


由于是每天早上8点30分执行,所以很理所当然地:

$ crontab -e
30  8    *    *    *    PATH_TO_SCRIPT/x.sh `date -d "-1 day" +%Y%m%d`

但是过了几天发现脚本根本就没有被处理(在某些机器上,cron fail时会将邮件发送给用户"You have new mail in /var/spool/mail/USERNAME")。

原因是坑爹的cron没法正确处理反引号。

解决办法是,额外写个脚本将这句命令包装,在crontab中执行包装脚本 在%前面都加上反斜杠。
Dec 2
Ubuntu Server 10.04 x86和x86_64下是8MB,RHEL4 x86下是10MB。开线程的开销真大。
#include <pthread.h>
#include <stdio.h>

void *thread(void *arg)
{
    size_t stacksize;
    pthread_attr_t attr;
    pthread_attr_init(&attr);
    pthread_attr_getstacksize (&attr, &stacksize);
    printf("Default stack size = %lu KB\n", stacksize / 1024);
}

int main(int argc, char *argv[])
{
    void *x;
    pthread_t t;
    pthread_create(&t, NULL, thread, NULL);
    pthread_join(t, &x);
    return 0;
}
Nov 2

闲谈 Restricted Function #2 不指定

felix021 @ 2010-11-2 13:36 [IT » 操作系统] 评论(0) , 引用(0) , 阅读(7077) | Via 本站原创
上一篇谈到:“典型的情况是某些非法内存访问,Glibc会open("/dev/tty",...),write()一些错误信息,然后open("/proc/self/maps", ...)把进程的内存映射表输出。还有一个更常见的情况,那就是用qsort。GCC的qsort实现,会主动open(/proc/meminfo),获取一些信息,通过这些信息来最优化排序时的内存管理。” 通过执行
strace ./a.out 2>&1 | grep open
可以看到进程执行的open系统调用。

对于这类情况,ptrace监控进程open系统调用,并获取文件名,检查文件名是否合法,如果合法,予以放行,这样就可以避免上述RE被误判为RF的情况了。

说起来很简单,但是具体做起来就有点麻烦。不过可以从我写woj-land的时候参考的ptrace教程《Playing with ptrace, 玩转ptrace》入手。这篇非常不错,强烈推荐有兴趣的同学学习学习:

Playing with ptrace, Part I — 玩转ptrace(一) http://www.kgdb.info/gdb/playing_with_ptrace_part_i/
Playing with ptrace, Part II — 玩转ptrace(二) http://www.kgdb.info/gdb/playing_with_ptrace_part_ii/

上篇以write系统调用为例,介绍了write系统调用的等价汇编码(当然是早期的了,现在的pc上linux貌似不用0x80了)、截获write系统调用,获取write系统调用的参数和返回值、甚至反转write系统调用的输出。具体的看原文了。

在这里,我需要peek的是read系统调用的参数。以x86为例,一个最简单的read系统调用:
read("/proc/meminfo", O_RDONLY)
,大致等同于
movl $5, %eax  ;open的系统调用编号
movl $filename, %ebx ;文件名地址(这里不一定对)
movl $0, %ecx ;open的flags: O_RDONLY
int $0x80
也就是说,可以通过获取x86 CPU寄存器的值来取得系统调用的参数,具体代码如下:
user_regs_struct regs;
ptrace(PTRACE_GETREGS, child, NULL, &regs);
syscall_id = regs.orig_eax; //因为eax也是用来填写函数返回值的,所以该struct额外增加了一个orig_eax
params[0]  = regs.ebx;
params[1]  = regs.ecx;
union u{ unsigned long val; char chars[sizeof(long)]; }data;
data.val = ptrace(PTRACE_PEEKDATA, child, params[0],  NULL);

注意:虽然ebx中存放的是地址,但是不是用户程序可以直接读取的,需要通过ptrace的PTRACE_PEEKDATA命令来获取。该命令一次可以获取sizeof(long)个字节的内容,如果要获取字符串的所有内容,就得通过循环来完成。

此外,为了保证代码能够在x86_64架构下通过编译,需要把上述代码做个小修改:
#if __WORDSIZE == 32
syscall_id = regs.orig_eax;
params[0]  = regs.ebx;
params[1]  = regs.ecx;
#else
syscall_id = regs.orig_rax;
params[0] = regs.rdi;
params[1] = regs.rsi;
#endif


通过这种方式,能够识别出open系统调用打开的文件,在保证系统安全的情况下,改善了Judge的识别能力。

更具体的代码可以参见:
http://code.google.com/p/woj-land/source/browse/trunk/code/judge/judge.h?spec=svn150&r=150#671
Aug 26
上一次的方法虽然达到了基本要求,但是还是有很多不爽的地方,尤其是

1. 当需要直接操作该虚拟机,或者修改运行时参数(比如增加共享文件夹、修改网卡的模式、分配光驱)时,需要将虚拟机关闭或者休眠,然后再重新用vbox打开,很麻烦,更重要的是当前ssh会话环境全都要关闭,再次建立很麻烦。

2. 由于虚拟机是后台运行的,在关机的时候可能会被忽略,影响数据的安全性,甚至会导致虚拟机挂掉——我遇到的情况是apt包管理器的缓存文件出错,无法安装或卸载现有程序。于是干脆重装了下(把alternate版换成了server版)。

于是上网搜了一下,找到一款很不错的绿色软件——RBTray,可以强制将软件放入托盘(Systray)中,隐藏它在任务栏占用的位置。

这款软件可以在这里下载:http://rbtray.sourceforge.net/

把它下载,解压,运行,然后右键单击窗口的最小化图标,绝大部分窗口就会最小化到托盘中去。

然后在桌面上额外创建两个bat文件:
start.bat
VBOX安装路径\VBoxManage startvm Ubuntu

stop.bat
VBOX安装路径\VBoxManage controlvm Ubuntu savestate


完美:D
Aug 22
一个简单的程序:
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/types.h>

int main(int argc, char *argv[])
{
    int fd = open(argv[1], O_CREAT | O_WRONLY);
    if (fd < 0)
    {
        printf("err open");
        return 1;
    }
    u_int64_t sz = lseek64(fd, (1ull << 40) - 1, SEEK_SET);
    if (sz < 0)
    {
        printf("err lseek64");
        return 2;
    }
    int nWrite = write(fd, &fd, 1);
    printf("nWrite = %d\n", nWrite);
    close(fd);
    return 0;
}


编译运行:
引用
$ gcc -o hole hole.c -D_FILE_OFFSET_BITS=64
$ ./hole disk
$ ls -lh disk
-rwxr-S--- 1 felix021 felix021 1.0T 2010-08-20 14:36 disk


搞怪:
引用
felix021@ubuntu-vbox:~/code$ mkdir mnt
felix021@ubuntu-vbox:~/code$ sudo mkfs.vfat disk
mkfs.vfat 3.0.7 (24 Dec 2009)
felix021@ubuntu-vbox:~/code$ sudo mount -oloop disk mnt
felix021@ubuntu-vbox:~/code$ df -lh
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda3            5.2G  1.5G  3.5G  30% /
...
/dev/sda1            2.3G  957M  1.3G  43% /home
/dev/loop0            1.0T  16K  1.0T  1% /home/felix021/code/mnt
Jul 27
在ISO C规范中有有一个很诡异的东西,那就是传说中的errno,一个有左值的int。当库函数出错的时候,它很可能会被设置为非0值;且没有任何一个库函数或系统调用会把它置为0。

刚接触到errno,可能会认为这是个在errno.h中用
int errno;
定义的整型。但是一旦开始写多线程的程序,再看到errno的时候,就会抑郁了。如果两个线程调用库函数都出错,那errno怎么办...?

幸而,ISO C并没有规定,errno必须是一个int,如果看errno的manpage (man errno) 会看到:
引用
errno may be a macro.  errno is thread-local; setting it in one thread does not affect its value in any other thread.
实际上GNU的glibc也就是这么实现的,(通常)在/usr/include/bits/errno.h里头:
#define errno (*__errno_location ())

于是errno就是个有左值的int了。至于这个__errno_location,在glibc的源码的 csu/errno-loc.c 里头:
int *
#if ! USE___THREAD
weak_const_function
#endif
__errno_location (void)                                                                                                                                     
{
  return &errno;
}

而这里的真正的errno,在 csu/errno.c 里头:
__thread int errno;

由于包含的都是errno.h,所以对于用户程序而言,可见的只有errno.h中的"errno",实际上是(*(__errno_location()),而__errno_location()返回的是errno.c中的errno的地址。可真绕啊。可是偏偏又不能把 __thread int errno; 放在errno.h中,为什么呢?其实原因很简单也很复杂——C语言真是个纠结的语言。

最后,解释一下“__thread”修饰符:__thread defines number to be a thread local variable. 定义thread-local的变量。详情参见Thread-local_storage的wiki页:http://en.wikipedia.org/wiki/Thread-local_storage
Mar 29
@2010-10-30 建議看 加強版: http://www.felix021.com/blog/read.php?1921

用VirtualBox在Windows上搭建一个Ubuntu工作站

目标
1. 没有多余窗口
2. Ubuntu少占资源
3. Ubuntu可以上外网
4. 可以ssh连上去搞开发

实现
1. 在Vbox上安装一个Ubuntu
2. 整两个网卡,一个host-only,一个NAT。
3. 安装好ssh-server
4. 如果有gdm(desktop/alternative),干掉 sudo update-rc.d -f gdm remove; cd /etc/X11/,在default-display-manager的第一行(gdm)前加个#注释掉
5. 编译这个东西,可执行程序放到program files\sun\virtualbox\下面,比如叫做startvm
#include <iostream>
#include <windows.h>
using namespace std;

int main(int argc, char * argv[])
{
    string param = string(" -startvm ") + argv[1];
    ShellExecute(NULL, "open",
            "vboxheadless", param.c_str(),
            "c:", SW_HIDE); //使用SW_HIDE就不会看到vboxheadless的命令行窗口了
    return 0;
}
6. 运行 startvm "虚拟机名"
7. 打开SecureCRT连上去干活吧
8. 可以使用VBoxManage controlvm "虚拟机名" start|poweroff|pause|resume|savestate...等来控制虚拟机的运行状态

其他
1. 如果需要开机自启动,稍微改改这个程序或者搞个bat扔到startup里面去,或者干脆注册一个服务。
分页: 3/17 第一页 上页 1 2 3 4 5 6 7 8 9 10 下页 最后页 [ 显示模式: 摘要 | 列表 ]