Greg daemon mode

[natir]

Why greg daemon mode

I search a cli podcast manager for download podcast and listen it with my ampache server.
Greg is the only good result, but greg haven't mode daemon.

Why didn't use greg sync in chron

First because i see this option after work 3 hours, and i didn't wanted get this work in trash.
Second because chron task isn't flexiblity like daemon.

Daemon process

Use daemonic module for :

• fork sub-process
• change the user and some environement variable
• redirect standard and error output
• generate pid file

For each feed :

• Check if is the first time feed call in daemon
  • Download the last podcast
  • Save the hour of the podcast
• Read the time of podcast in remote feed and in save file
• If local is odler of remote :
  • Download the last podcast
  • Save the hour of the podcast
• Else :
  • Nothing

Stop command :

• Kill the worker process.
• Erase the pid file.

Option

--time : Required option, set the time (in second) after previous check to rerun

--user : Required option, the name of worker user

--log-dir : Default "/var/log/greg", the flooder of log file

--pid-file : Default "/var/run/greg/greg.pid", the path of pid file

Note

I make change in daemonic, the pull request not yet accepted. You can use https://github.com/natir/daemonic, for test my code.

[manolomartinez]

Hello, Pierre, thanks a lot for the effort you've put into this pull request. Could you please walk me through the benefits that you see in using your daemon mode, as opposed to a simple cronjob? You mention flexibility; I'd like to know more about what you have in mind.

Cheers,
Manolo

[natir]

Sorry for that, i didn't develop this fact, in my pull request.

An example if i run greg with crontab, and i want stop or change some parametre, i need run crontab with the run user greg, to change this (comment line for stop or change the parametre). Close the crontab editor, and wait cron rerun my command for test my change.

With daemon, just run one command for stop, and an other for restart with other parametre(if this i want), and i no wait for check the effect of my new parametre.

With crontab you need edit file and wait, with daemon no edit and no wait.
Yes if you use daemon manager, like systemd, if you want change parametre you need edit file for set parametre, but you didn't wait for see the effect like crontab task.

This not make a big difference i know, but just add freedom in greg possibility usage.

Thanks for your interest
Pierre

[natir]

Wheel done, you accept my pull request or not ?

[manolomartinez]

Hello, Pierre.

I've been thinking about your pull request, and I don't think it's a good idea to accept it:

• First, as you say, it depends on other packages as modified by you. If I pull this, I break greg until your proposed changes to daemonic go through.
• Second, and most important, I am not sure that the added functionality should be provided by greg. I am, though, willing to think of ways in which the kind of daemonizing that you have in mind might be implemented (perhaps a systemd --user unit?) and add it to this repository, and the greg distribution. If you can come up with ways (outside of the core greg) in which the kinds of on the fly changes that you have in mind might be implemented, I'd be happy to consider them.

Best,
Manolo

[natir]

Hello, Manolo

Pull-request in upstream is probleme I agree, your argumentation. I can rewrite for daemonize use a differente way.

I think daemonize with init system is ugly, and not protable (no systemd in Debian like or BSD) and some litle difference in distribution may be need to write script for all different linux.

The only core greg modification modification, in core greg is for add commande line option, and factorising function. If you add a plungin system, may bee i can rewrite modification to become a plugin.

Best,
Pierre

[manolomartinez]

The only core greg modification modification, in core greg is for add commande line option, and factorising function. If you add a plungin system, may bee i can rewrite modification to become a plugin.

That sounds interesting. I will think of that. Thanks!