Schedule::Cron process name?

bowei_99 has asked for the wisdom of the Perl Monks concerning the following question:

Hi all, I've been using Schedule::Cron, and it's been working well. My one gripe is that there's no reference to the script (vdcs_errors.pl) that calls the cron job in the process table. In other words, if I grep the process table for the PID of the perl script (i.e. the contents of the variable $$), I get the following, which has no mention of vdcs_errors.pl:

# ps auwwx | grep 3166
root     31663  0.1  0.0 66376 5600 pts/5    S    02:53   0:00 Schedul
+e::Cron MainLoop - next: Mon Jun 19 15:00:00 2006
[download]

I tried using nofork => 1 when defining the cron object, but still the same thing. I also looked at Schedule::Cron::Nofork, and I'm a little leery of what it says, since I may be using this for other jobs:

... It has the disadvantages that one long running job can disrupt the rest of the schedule and that a programming error in one job will bring down the whole program. Anybody have ideas? Perhaps it's not hitting me from reading the documentation on cpan.

-- Burvil

Comment on Schedule::Cron process name? Select or Download Code

Replies are listed 'Best First'.
Re: Schedule::Cron process name? by Tanktalus (Canon) on Jun 19, 2006 at 03:50 UTC
What I think you're looking for is to set `$0` to something useful. It appears that Schedule::Cron is already setting it to something, and you'd rather it was set to something else. Since this is as simple as assigning what you want to $0, perhaps it's sufficient to do so in your methods? Depends, I suppose, whether you're talking about the main process's process table entry, or the forked-off child processes.	[reply] [d/l]
Re^2: Schedule::Cron process name? by bowei_99 (Friar) on Jun 19, 2006 at 08:12 UTC
Update: I tried printing out what $0 is after I'd defined the Schedule::Cron object and added an entry, but before I ran the cron. It must be somewhere in the run method in the module that it redefines what $0 is, or at least what the process name is, as when I print the value of $0, it still shows the name of the script. So, even if I reassigned the contents of $0, it wouldn't change what shows up in the process table. Hm, I see what you're saying. But since $0 is by default the name of the script (which is what I want), and thus what a lot apps depend on, is it bad to change that? I guess maybe this is a question for the author of Schedule::Cron .... I mean, it is nice to see module name and the next time it will run, but for maintainability, I need the name of the script in there, too. -- Burvil	[reply]
Re^3: Schedule::Cron process name? by Tanktalus (Canon) on Jun 19, 2006 at 15:03 UTC
You're right - $0 is set in Schedule::Cron's run method. And, unfortunately for you, that method is a behemoth method which does not give you a lot of flexibility to change anything about it. For example, if you were to derive your own package from S::C, you'd have to pretty much copy and paste the entire method to your own module, minus the one line that sets $0. And then, if a new version of S::C came out with a fix, you'd have to notice and merge the fix manually. That's kinda annoying. Instead, what I would suggest you do is take the S::C module, change the line that says `$0 = ...` to say `$self->set_process_title()`, add a new method called set_process_title that all it contains is the old $0-setting line, take a diff between what you have and the original, and submit it back to the author of S::C as a patch. Once you have that, then you can create your own Schedule::Cron::NoProcessTitleChange, which @ISA Schedule::Cron, and overrides set_process_title with an empty function (i.e., it does nothing). Then you'll get what you are looking for. Assuming, of course, that the author likes the patch... though, since we're not actually changing real behaviour, s/he should be fine with, I hope.	[reply] [d/l] [select]
Re^4: Schedule::Cron process name? by bowei_99 (Friar) on Jun 19, 2006 at 23:24 UTC
Re: Schedule::Cron process name? by Corion (Patriarch) on Jun 19, 2006 at 07:12 UTC
As the author of Schedule::Cron::Nofork, I can tell you how I circumvent the problem of long running tasks - I do the detachment within the started program, by using the `start` command of the Windows shell instead of relying on the buggy fork() implementation of Win32 Perl, which I experienced to have problems over the long term. After 3 or four days of spawning something every ten minutes, the main thread would just sit there. Other than that, Schedule::Cron::Nofork is the same as Schedule::Cron, so it won't be a solution for your problem I think.	[reply] [d/l]