Halfway point between interactive and daemon?
I have a python3 program that performs a long running service on a semi embedded linux device. I've been in the prototyping stage. I just run it from the command line and use print() statements to let me know the thing is making acceptable process. At some point, I need to properly daemonize it. Write an init script, find a logging framework/module, batton all the hatches down, so to speak. I’m curious if there’s a technique one could use to get half way there. Basically, with minimal modifications, I’d like to get it running at startup. So I can put a line like this in rc.local nohup python3 myMain.py 21 /var/log/mylog.log Then I can “check” on it when I need to with a tail -f /var/log/mylog.log. But then I have the problem of managing the log size. And also I either have to wait for stdout to flush, or insert sys.stdout.flush() after any of my print()’s. I haven’t done a lot of these daemon processes (and this is my first with python), so I was curious what those with experience do here. -- https://mail.python.org/mailman/listinfo/python-list
Re: Halfway point between interactive and daemon?
Travis Griggs travisgri...@gmail.com: nohup python3 myMain.py 21 /var/log/mylog.log I don't recommend this (ubiquitous) technique. You should keep your daemon in the foreground until it has reserved and initialized all the resources it needs and daemonize only then. That way the caller does not have to guess when the service is really available. The proper daemonization procedure is here: URL: http://code.activestate.com/recipes/66012-fork-a-dae mon-process-on-unix/ Now, with the new systemd standard, there is a way for you to inform the system when a service is up even after backgrounding. I have no personal experience with that technique. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Halfway point between interactive and daemon?
On Sat, Aug 23, 2014 at 5:27 AM, Travis Griggs travisgri...@gmail.com wrote: I’m curious if there’s a technique one could use to get half way there. Basically, with minimal modifications, I’d like to get it running at startup. Okay, hold on a minute there. There are two quite separate things here: daemonization, and starting on system startup. Daemonization is actually unnecessary to the latter, if you use a modern init system. Just write your program to never fork, and either Upstart or systemd will happily monitor it. Just create a unit file, something like this: [Unit] Description=Yosemite Project [Service] Environment=DISPLAY=:0.0 User=whichever_user_to_run_as ExecStart=/usr/bin/python /path/to/your/script # If the network isn't available yet, restart until it is. Restart=on-failure RestartSec=10 [Install] WantedBy=multi-user.target $ systemctl --system daemon-reload $ systemctl enable yos.service $ systemctl start yos.service (Feel free to steal that for your own purposes. It came from my MIT-licensed videos server project Yosemite.) Daemonization should be optional. The above unit file works fine for something that doesn't fork itself away. (I'm not sure how systemd works with daemonizing processes, never tried. In any case, it's unnecessary.) If you do need it (so the user can start your program from the command line), I strongly recommend picking up a module off PyPI; there are actually a lot of little details that people will expect you to have gotten right. May as well bury it all away in a little daemonize() call :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Halfway point between interactive and daemon?
On 22Aug2014 12:27, Travis Griggs travisgri...@gmail.com wrote: I’m curious if there’s a technique one could use to get half way there. Basically, with minimal modifications, I’d like to get it running at startup. So I can put a line like this in rc.local nohup python3 myMain.py 21 /var/log/mylog.log Just to this. You have your redirections backwards. They are applied left to right. So, first 21: sending stderr to where stdout currently goes (probably the system console if this runs from rc.local). Then, /var/log/mylog.log: sending current stdout to the log file. Importantly, _not_ attaching stderr to the log file. You want to write this: command log 21 As others have remarked, you do not need to daemonise a process started from rc.local. And as others have remarked, if you want it to start/stop under external conrol, or restart after a program abort etc, you may be better adding it as to the configuration of something like systemd or init. That said, I start a bunch of things in rc.local. It is quick and easy, and also handy for stuff that shouldn't be restarted automatically if it dies. Then I can “check” on it when I need to with a tail -f /var/log/mylog.log. But then I have the problem of managing the log size. And also I either have to wait for stdout to flush, or insert sys.stdout.flush() after any of my print()’s. Log messages should be going to stderr anyway, which by default is unbuffered. Cheers, Cameron Simpson c...@zip.com.au You can't have everything... where would you put it? - Charles Robinson, cr0...@medtronic.com -- https://mail.python.org/mailman/listinfo/python-list
