Native upstart scripts
Hello, In PLD Th, we have upstart as the /sbin/init daemon for some time, but it is only used to start the old 'SysVinit' scripts from /etc/rc.d/init.d. To make full use of Upstart features, like process supervising, parallel start, etc. we should find a way to include Upstart support in our packages. Though, we should not replace the current, working solution. I think Upstart support should be implemented as an option, coexisting with current solution, so the administrator may choose what he prefers and even use init.d for some services and upstart for other. My proposition: - packages will provide upstart configuration files in /etc/rc.d/upstart - those could be linked or copied to /etc/init/subsys when needed - chkconfig would link/unlink the files when requested (global configuration option and command line option to prefer upstart) - user could copy them manually and modify them if needed - rc-scripts won't start/stop services via /etc/rc.d/init.d scripts when /etc/init/subsys/$name exists - 'service' script would use 'initctl' instead of /etc/rc.d/init.d when /etc/init/subsys/$name exists - scripts in /etc/rc.d/init.d would emit 'started' and 'stopped' events when necessary, so upstart services can rely on that What do you think? Should I try to prepare a proof-of-concept implementation? P.S. Does anybody read those 'long' posts I send to pld-devel-en? ;) ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Native upstart scripts
2010/5/4 Jacek Konieczny jaj...@jajcus.net: I think Upstart support should be implemented as an option, coexisting with current solution, so the administrator may choose what he prefers and even use init.d for some services and upstart for other. +1 - chkconfig would link/unlink the files when requested (global configuration option and command line option to prefer upstart) Your implementation sounds reasonable. I have several systems I will be interested in trying this out on. P.S. Does anybody read those 'long' posts I send to pld-devel-en? ;) Yes. Particularly as a new developer seeing verbose discussion of various decisions is quite helpful. Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Native upstart scripts
On Tuesday 04 May 2010 12:17:41 Jacek Konieczny wrote:
What do you think? Should I try to prepare a proof-of-concept
implementation?
i describe ubuntu like implementation that i had in first mind to do:
1. some packages have been migrated to upstart,
having /etc/init/service.conf file
2. those packages initscript is symlinked:
to /etc/rc.d/init.dservice - /lib/init/upstart-job
3. upstart-job suggests to use 'service service to start if invoked directly
via /etc/rc.d/init.d
4. /sbin/service, sees if invoked service jas /etc/init/service.conf and
invokes via upstart, otherwise fallbacks to sysvninit mode
upstart-job is included in upstart package, /sbin/service diff in attachment.
however this assumes you already have upstart in target, i.e you preserve
invoking old way, but require upstart being present.
and this does not handle chkconfig integration due the symlink, i.e booting
without upstart sequence is unknown.
i've also packaged two packages from ubuntu to pld: mountall and ureadahead
P.S. Does anybody read those 'long' posts I send to pld-devel-en? ;)
i would had answered bacula one, if i had chance to test bacula 5.0
--
glen
--- service 2010-04-21 23:22:56.221265599 +0300
+++ /sbin/service 2010-04-21 23:24:13.564399085 +0300
@@ -95,6 +95,21 @@
esac
done
+if [ -r /etc/init/${SERVICE}.conf ]; then
+ # Upstart configuration exists for this job
+ case ${ACTION} in
+ start|stop|restart|status|reload)
+ # Action is a valid upstart action
+ exec ${ACTION} ${SERVICE} ${OPTIONS}
+ ;;
+ force-reload)
+ # Upstart just uses reload for force-reload
+ exec reload ${SERVICE} ${OPTIONS}
+ ;;
+ esac
+fi
+
+# Otherwise, use the traditional sysvinit
if [ -x ${SERVICEDIR}/${SERVICE} ]; then
exec env -i LANG=$LANG PATH=$PATH TERM=$TERM ${SERVICEDIR}/${SERVICE} ${ACTION} ${OPTIONS}
else
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Native upstart scripts
On Tue, May 04, 2010 at 12:04:39PM +0200, Patryk Zawadzki wrote: I think Upstart support should be implemented as an option, coexisting with current solution, so the administrator may choose what he prefers and even use init.d for some services and upstart for other. I was hoping for eventually dropping rc scripts for some services and moving them completely to upstart. I see why that might sound scary and am ok with having two solutions. I think we can drop rc-scripts some day, but first the alternative must be well-tested. Having the two alternatives co-exist every one may gradually migrate to upstart in his own pace. And dropping /etc/rc.d/init.d/* in Th will make another difference to Ti… I guess we don't wont PLD split even more. Another thing to consider is LSB compatibility… some services expect /etc/init.d scripts doing their stuff. Maybe we could make /etc/init.d a directory with symlinks to /etc/rc.d/init.d or the upstart wrapper, depending on what is used to handle the service? I'd opt for having 2 separate -init subpackages, one with the current rc.d contents and one with an upstart job description and a simple rc.d wrapper that runs start $foo, stop $foo etc. Extra two subpackages for every daemon? I would prefer to avoid that. As for emitting signals, we should add these as required by dependencies. I see no gain from adding them to every rc.d script. Hmm. That makes sense. Some event will be implemented in rc-scripts (line 'network started'). On the other hand, if we make rc-scripts function which does touch /var/lock/subsys/$name; initctl emit subsys/$name started and another to: rm -f /var/lock/subsys/$name; initctl emit subsys/$name stopped Then integrating the signals will be very easy. Greets, Jacek ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Native upstart scripts
On Tue, May 04, 2010 at 12:04:39PM +0200, Patryk Zawadzki wrote: - scripts in /etc/rc.d/init.d would emit 'started' and 'stopped' events when necessary, so upstart services can rely on that I'd opt for having 2 separate -init subpackages, one with the current rc.d contents and one with an upstart job description and a simple rc.d wrapper that runs start $foo, stop $foo etc. There is one more thing why I would prefer to keep both old-style init.d script and the new upstart configuration together: we often have something more than 'start' 'stop' and 'status' implemented in the init scripts. Some of these actions would have to be copied to upstart script somehow (initialization before first run), other probably cannot be handled by upstart means. sshd init script builds host keys the first time it is started. This functionality is available also via '/etc/rc.d/init.d/sshd init' and would have to be copied to the upstart configuration to and maintained in the two places. As starting and stopping of services is quite different in LSB init scripts and upstart and reusing code does not make sens, in other cases, like 'init' the code may be reused and upstart script could just call '/etc/rc.d/init.d/sshd init'. Also, there are things like '/etc/rc.d/init.d/lighttpd configtest' which are not part of normal job control and thus not applicable to upstart config, but still useful. Greets, Jacek ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Native upstart scripts
On Tue, 4 May 2010, Patryk Zawadzki wrote: I think Upstart support should be implemented as an option, coexisting with current solution, so the administrator may choose what he prefers and even use init.d for some services and upstart for other. I was hoping for eventually dropping rc scripts for some services and moving them completely to upstart. I see why that might sound scary and am ok with having two solutions. -ENOWAY ! Don't remove working sollution. It can be done for new services, but not for existing-ones. I'd opt for having 2 separate -init subpackages, one with the current rc.d contents and one with an upstart job description and a simple rc.d wrapper that runs start $foo, stop $foo etc. I wanted to say something like that. What do you think? Should I try to prepare a proof-of-concept implementation? Ladies and gentlemen, we have a volunteer :) hip-hip, hura!!! ;) -- pozdr. Paweł Gołaszewski jid:bluesatjabberdotgdadotpl -- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free.___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Native upstart scripts
On Tue, 4 May 2010, Jacek Konieczny wrote: Maybe we could make /etc/init.d a directory with symlinks to /etc/rc.d/init.d or the upstart wrapper, depending on what is used to handle the service? see how ubuntu made this. Every service is in that directory, some are links. I can see how does it looks like at home, later. I'd opt for having 2 separate -init subpackages, one with the current rc.d contents and one with an upstart job description and a simple rc.d wrapper that runs start $foo, stop $foo etc. Extra two subpackages for every daemon? I would prefer to avoid that. but you can make ignores in poldek with that and make it easy to use. -- pozdr. Paweł Gołaszewski jid:bluesatjabberdotgdadotpl -- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free.___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Native upstart scripts
On Tuesday 04 May 2010 12:17:41 Jacek Konieczny wrote: My proposition: - packages will provide upstart configuration files in /etc/rc.d/upstart - those could be linked or copied to /etc/init/subsys when needed - chkconfig would link/unlink the files when requested (global configuration option and command line option to prefer upstart) - user could copy them manually and modify them if needed i don't like the idea that the links are managed via some script, i'd like easily to boot to upstart-mode or sysvinit-mode with a kernel commandline, or something in /etc/sysconfig/system the both solutions should be available and configured at the same time. also i'd not invent new paths, but use /etc/init for upstart scripts. - rc-scripts won't start/stop services via /etc/rc.d/init.d scripts when /etc/init/subsys/$name exists - 'service' script would use 'initctl' instead of /etc/rc.d/init.d when /etc/init/subsys/$name exists - scripts in /etc/rc.d/init.d would emit 'started' and 'stopped' events when necessary, so upstart services can rely on that otherwise matches quite much with my vision... -- glen ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Native upstart scripts
On Tue, May 04, 2010 at 07:40:43PM +0300, Elan Ruusamäe wrote: On Tuesday 04 May 2010 12:17:41 Jacek Konieczny wrote: My proposition: - packages will provide upstart configuration files in /etc/rc.d/upstart - those could be linked or copied to /etc/init/subsys when needed - chkconfig would link/unlink the files when requested (global configuration option and command line option to prefer upstart) - user could copy them manually and modify them if needed i don't like the idea that the links are managed via some script, i'd like easily to boot to upstart-mode or sysvinit-mode with a kernel commandline, or something in /etc/sysconfig/system the both solutions should be available and configured at the same time. I'll take this into account. Though keeping both configured could cause mistakes like starting a service again the different way. I guess this can be solved somehow anyway also i'd not invent new paths, but use /etc/init for upstart scripts. Recent upstart allows hierarchical names. I thought a separate namespace (subsys/* or rc/*) for the rc-scripts equivalents would be a good idea. Now I think it will be probably better to use subdirs for local stuff (/etc/init/local - local/* jobs) and sub-tasks (e.g. /etc/init/postgresql.conf – 'postgresql' task to start/stop whole postgresql and /etc/init/postgresql/instance.conf – 'postgresql/instance' describing each instance) instead. Greets, Jacek ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
