Did you really mean “started”? or it’s a typo? I’d expect post-stop to be executed for every time that the job is stopped

My perl script takes an –start option to start and –stop to stop. How do I tell upstart to use that input argument as start up and shut down?

thanks for the help

Next how do I write a Upstart init.d file to replace a SYSV formatted file I used under Fedora, or a Debian based init.d for Ubuntu? Again, an example would be nice. I can supply an autotools package with debian|redhat.initd templates, and two versions of the same C template daemon; libc & glib based with only –userid username –version –force (pid create) –help, if that would help. Its on my sourceforge page with gapcmon. gdaemons-0.1.1.tar.bz2 https://sourceforge.net/project/showfiles.php?group_id=157888&package_id=280067&release_id=606274

I ask because I am interested in what your doing and there is a benefit for me; one init.d script for all linux platforms (WooHoo). Thus, I want to understand how the two or three daemons I have released will be advantaged by upstart. I have no problem adding dbus, although I already create a pid file. Also I always fork once, but that two can be changed. I’m looking for the book or some best practces that I can code to. Most of what i have googled on UpStart has been difficult to piece together and code to.

If you’ve already contacted Chris Lee, that’s good. He might take a while to update PlanetKDE — I know it took about 2 weeks for my name to appear on the list.

The biggest argument is clarity. You’ve already got ‘exec’ to differentiate from ‘script’. But the popular scripting language in people’s minds shifts from year to year. A few years ago it would’ve been Perl. These days it’s Python.

Another weaker argument for having aliases is the possibility of defining them in a config file. That way if someone wants “shell” to mean “/bin/posh” on their system, they can change it in one place instead of sed’ing all of the config files.

@tomasz, @jef: the entire point of the new version is to fix the problems that prevented us from taking full advantage of it. Fedora won’t have much luck without it either, and it’s in their roadmap as well

@liquidat: yes, we’re talking quite a lot

@vlad: up to the PlanetKDE admins I guess