docker中无法使用crontab的问题

最近在docker里使用crontab设置定时任务,发现crontab到时间没有执行。

第一个想到的是时区问题,查看了一下时区,是UTC时区,赶紧改成了Asia/Shanghai

使用date命令查看,时间没问题了。设置个时间测试一下,结果仍然不执行。

检查crontab任务是否启动

一切正常啊,奇怪。

装上rsyslog并启动,查看相关日志:

里面说set_loginuid failed,这个似乎是个认证模块,因为安全原因,被docker默认禁用掉了。修改/etc/pam.d/cron,把下面这行注释掉(也可以使用更高的权限启动容器,比如gdb无法使用的情况):

也可以把中间的required修改为optional来解决。

重启cron,运行成功。

同样的,ssh也会有这样的问题,因为也用到了pam认证模块,可以参考下面给出的链接来解决。

参考:

docker容器中crontab无法正常运行解决方案
Dockerize an SSH service

环境参考:

Docker版本:1.13.1
系统:archlinux

pandas datareader v0.6.0获取雅虎财经数据报错问题

使用pandas datareader的时候,报如下错误:

去datareader的文档页查看原因,有一个这样的提示:

As of v0.6.0 Yahoo!, Google Options, Google Quotes and EDGAR have been immediately deprecated due to large changes in their API and no stable replacement.

到了v0.6.0的时候Yahoo!, Goole Options, GoogleQuotes和EDGAR的api有大改动,目前还在调整,不够稳定。
还有一段这样的提示:

Yahoo! Finance has been immediately deprecated. Yahoo! substantially altered their API in late 2017 and the csv endpoint was retired.

看起来是雅虎财经的api在2017年末做了修改,csv的数据也取消了。所以数据源里暂时不提供雅虎财经的数据了。

来源:

https://pydata.github.io/pandas-datareader/stable/

https://pandas-datareader.readthedocs.io/en/latest/remote_data.html

LL(1)文法分析

自顶向下

自顶向下是一种从开始符号推导出输入符号所对应的语法的过程,举个例子:

上面便是个从开始符号S出发,推导出aabb语法情况的过程,可以通过这个信息产生语法树。

那么如何推导呢?下面是通过一个栈来做的穷举推导过程,这种推导是需要回溯的:

上面的例子里面,出栈一个非终结符的时候,便从这个终结符的几个产生式里找一个做尝试,如果此路不通,就回退到尝试的路口,然后换一个产生式继续努力,直到找到一条看起来可以走下去的路继续重复以上的步骤(如果所有产生式都不能走通,就判断为语法有问题)。

可以想象,如果从A开始就选错了产生式,然后B尝试了所有产生式都没走通,那么回溯的层次就不仅仅是B自己一层了。这就好像一条路有X个岔路,然后每个岔路又有各自Y个岔路,而每个子岔路下面仍然有可能有Z个岔路,而目的地是X5Y2Z8,这种做法好像赌博碰运气一样,看天吃饭。有没有其他好的方法呢?

继续阅读

探索Ruby正则表达式算法(译)

来源:Exploring Ruby’s Regular Expression Algorithm(2012)

ps. 业余翻译的,求轻拍。有什么问题可以直接指出。

大家都熟悉正则表达式,它是开发者的“瑞士军刀”。不管你想查找哪种信息,解析哪些字符串,总有一种正则表达式适合你。事实上,你可能用过很久的ruby所使用的正则表达式了——正则表达式已经被集成到几乎所有主要的语言中好多年了:Perl、javascript、PHP、Java等等。ruby支持是在90年代中期,而正则表达式是在60年代中期发明的,早了30年。

但是正则表达式是怎样工作的呢?如果你对正则表达式引擎后面的计算机原理感兴趣的话,可以读一下这三篇Russ Cox写的极棒的文章:

在这里我不打算重复Russ的内容。但是我准备在第二篇文章中快速的解释一下ruby所使用的“无递归的回溯实现”, 这意味着它可能也会像perl正则表达式一下慢吞吞。就是说,这意味着Ruby并没有使用目前最主流的正则表达式实现方法——Thompson NFA,也就是Russ第一篇文章中所描述的。

今天我们细看一下Oniguruma,也就是Ruby所使用的正则表达式引擎。我们使用一些插图来表现一些简单的正则示例,以此来弄清楚在使用正则的时候是Ruby内部是如何工作的——它比你想象的要复杂多了。

继续阅读

mail core2编译脚本执行失败的问题

今天编译mail core2的时候发现curl一直下不回文件,导致编译失败,错误如下:

应该是curl下载失败了。

自己手动执行了一下curl命令,或许是我的curl版本有问题,下回来的文件大小为0。

用curl -I 拿回来的头Content-Length并没有什么问题,状态码也是200。

或许是网络问题,或许是curl的bug,curl版本 7.43.0。

既然没查出原因,就先绕条路,把curl下载改为wget(mac需要额外安装,使用brew就可以),把mailcore2项目scripts/include.sh目录下的build-dep.sh(约325行):

替换为

再编译,就通过了。

至于curl无法通过的原因,待查。

两个PHP代码片段

最近有同事碰到两个问题:

这段代码输出什么?

这段呢?

第一个代码输出true,原因在于in_array使用了==的逻辑(如果第三个参数为true则为===的逻辑),不知道这样是否合理。源码中php将字符串转成了数字,转不了则返回0。(以上测试版本为5.5.30和7.0.0)

第二个代码输出:

因为第一次使用了引用,引用计数不释放,引用的地址是数组中c的地址。第二次循环对$m赋值的时候,不停的修改了$m指向的地址,数组中的地址也就发生了变化。赋值的源码位在于zend_execute.c/zend_assign_to_variable方法中。

红黑树

红黑树是一种很常用的自平衡二叉树。之前写过二叉搜索树,我们知道二叉搜索树查找速度是由树的高度决定的,但是因为二叉搜索树对树的平衡没什么限制,如果所有节点都在一个叉上,就变成了链表了。红黑树作为二叉搜索树的同时,用以下五个性质保证了树的平衡:

  1. 节点是红色或黑色。
  2. 根是黑色。
  3. 所有叶子都是黑色(叶子是NIL节点)。
  4. 每个红色节点必须有两个黑色的子节点。(从每个叶子到根的所有路径上不能有两个连续的红色节点。)
  5. 从任一节点到其每个叶子的所有简单路径都包含相同数目的黑色节点。

因为这些性质,一棵红黑树尽量保持每个路径上节点数差距不大,从来保证了树的查找速度。

红黑树

红黑树是一颗二叉搜索树,其查找方法自然也就是二叉搜索树的查找方法。因为给二叉搜索树节点涂了颜色,树上面的修改操作(如插入、删除)会影响红黑树的某些性质,恢复其性质需要需要O(log n) 次操作。

继续阅读

二叉查找树

二叉查找树英语Binary Search Tree),也称二叉搜索树、有序二叉树(英语:ordered binary tree),排序二叉树(英语:sorted binary tree)。二叉查找树是基础性数据结构,用于构建更为抽象的数据结构,如集合multiset关联数组等。

二叉查找树是指一棵空树或者具有下列性质的二叉树

  1. 若任意节点的左子树不空,则左子树上所有结点的值均小于它的根结点的值;
  2. 若任意节点的右子树不空,则右子树上所有结点的值均大于它的根结点的值;
  3. 任意节点的左、右子树也分别为二叉查找树。
  4. 没有键值相等的节点(英语:no duplicate nodes)。

注:维基百科和百度百科上性质【1】和【2】不同,描述中的一个性质会存在键值相等的情况,考虑到性质【4】,是不应该存在这个相等情况的。

注:以上定义摘自维基百科(微幅修改)。

二叉查找树相比于其他数据结构的优势在于查找、插入的时间复杂度较低,等于树高,期望为O(log n),最坏为O(n)。

二叉查找树

两个高度相同的二叉查找树

上面的两个二叉查找树树高是一样的,但是查找是速度是相同的。

下面介绍二叉查找树的一些操作:

继续阅读

PHP访问类私有元素

从PHP5开始,我们通过反射类来访问私有方法:

继续阅读