【问题标题】:Cron execution of python script not working like expectedpython脚本的cron执行没有像预期的那样工作
【发布时间】:2016-05-05 04:36:49
【问题描述】:

我有一个由 cron 执行的 python 脚本,它的目的是管理从用户到其他用户的消息。这些消息存储在 mongodb 数据库中。脚本爬取消息,查找目标名称, 从数据库中获取它的 _id 并将消息数据存储在用户消息数组中。之后,该消息将从消息集合中删除。

如果我手动执行 python 脚本一切正常,但如果 Cron 运行它,用户将不会更新但消息将被删除。

mongodb 服务器是 2.4.10,我知道它很旧,但它是在树莓派 2 上运行的最新版本,afaik。 python版本为2.7.x

# ...
# find all messages in messages collection
cursorMsg = db.messages.find({})

# iterate over every key in cursor
for keyMsg in cursorMsg:
    body = keyMsg["body"]
    about = keyMsg["about"]
    created_at = keyMsg["created_at"]
    sender_id = keyMsg["sender_id"]
    cursorUsrSender = db.users.find({"_id": str(sender_id)})
    sender_name = keyMsg["sender_name"]
    sender_id = keyMsg["sender_id"]
    to = keyMsg["to"]
    _id = str(keyMsg["_id"])

    # find the user for the message
    cursorUsrTarget = db.users.find({"username": to})
    for keyUsrTarget in cursorUsrTarget:
        print(keyUsrTarget)
        usr_target_id = str(keyUsrTarget["_id"])
        print(type(keyUsrTarget["messages"]))
        new_message = {
            "_id": _id,
            "created_at": created_at,
            "about": about,
            "body": body,
            "sender_id": sender_id,
            "sender_name": sender_name,
            "target_id": usr_target_id
        }
        # save the message
        keyUsrTarget["messages"].append(new_message)
        db.users.save(keyUsrTarget)
        # delete the message from message collection
        db.messages.remove({"_id": keyMsg["_id"]})

有没有办法在保存成功后等待保存命令的响应或者其他方式来执行删除命令?

转储:

{u'username': u'test', u'hash': u'$2a$10$Irwx.S5gwpOOB/gAxHPAv.Fpge9i6H.mEIh.RrAwfLp.qboZwm2sq', u'firstName': u'test', u'lastName': u'test', u'schiffe': [{u'kriegsschiffe': {u'galleone': u'0', u'karaken': u'0'}}, {u'handelsschiffe' : {u'koggen': u'0', u'schoner': u'0'}}], u'messages': [], u'fresh_account': u'false', u'test': u' 0', u'islands': [{u'buildings': {u'resource_stores': [{u'capacity': u'1', u'level': u'1', u'max_capacity': u' 1000', u'attack': u'100', u'health': u'100', u'type': u'Holzspeicher'}, {u'capacity': u'1', u'level': u'1', u'max_capacity': u'1000', u'attack': u'100', u'health': u'100', u'type': u'Steinspeicher'}, {u'容量': u'1', u'level': u'1', u'max_capacity': u'1000', u'attack': u'100', u'health': u'100', u'type ': u'Eisenspeicher'}, {u'capacity': u'1', u'level': u'1', u'max_capacity': u'1000', u'attack': u'100', u 'health': u'100', u'type': u'Nahrungsspeicher'}], u'main_buildings': [{u'type': u'Hauptgeb\xe4ude', u'attack': u'100', u'健康':u'100',u'level': u'1'}, {u'type': u'S\xe4gewerk', u'attack': u'100', u'health': u'100', u'level': u'1'}, {u 'type': u'Steinbruch', u'attack': u'100', u'health': u'100', u'level': u'1'}, {u'type': u'Schmelzofen' , u'attack': u'100', u'health': u'100', u'level': u'1'}, {u'type': u'M\xfchle', u'attack': u'100', u'health': u'100', u'level': u'1'}, {u'type': u'Hafen', u'attack': u'100', u'health ': u'100', u'level': u'1'}, {u'type': u'Forschungsgeb\xe4ude', u'attack': u'100', u'health': u'100' , u'level': u'1'}, {u'type': u'Handelsdepot', u'attack': u'100', u'health': u'100', u'level': u' 1'}, {u'type': u'Fort', u'attack': u'100', u'health': u'100', u'level': u'1'}]}, u' island_name': u'Insel 19', u'coordinates': {u'y': 450, u'x': 250}, u'ocean': 0, u'shape': 67, u'owner': u '测试',u'_id':u'57246661e844a270258159f1'}],u'_id':ObjectId('57283a079d3a22c819ca8600')} 消息发送给用户。 已从收藏夹中删除消息。

crontab

*/1 * * * *  pi ( python /home/py/menage_messages.py >> /home/log/messages.log )

【问题讨论】:

  • 是否可能存在某种竞争条件?但我不明白的是,如果我手动启动脚本,它会很好地工作。 cron 执行脚本时出现问题。
  • 你可以将 cron 的结果记录到一个文本文件中,看看有什么问题吗? * * * * * /full/path/of/your/script.py > text_dump ,加上确保你有完整的路径
  • Cron 运行良好,问题是删除执行速度比更新快。我认为这是一个竞争条件,但我不确定。

标签: python bash mongodb cron pymongo


【解决方案1】:

与手动执行脚本的环境相比,Cron 作业在不同的环境中运行。正如上述评论中所建议的,您可以尝试将 stdout 和 stderr 重定向到一个文件,然后查看将脚本作为 cron 作业运行时发生了什么。

【讨论】:

  • 我想我找到了问题所在,还有另一个 cronjob 正在运行并更新用户集合中的其他一些字段。
猜你喜欢
  • 2023-01-01
  • 1970-01-01
  • 2016-06-19
  • 2013-04-11
  • 1970-01-01
  • 1970-01-01
  • 2021-02-08
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多