> However after 3 attempt at executing the start method SMF marks my > service as failed and > proceeds to enable both dependent services. > I want the custom service to execute the start method once only > and never timeout, while waiting
You need to set the start method timeout to 0 not 60. -- Renaud dMark Duggan wrote: > Hi Liane, > > Got a little further ! > > I now have my custom service (control_startup) sending output to and > taking input from the console > during the boot process. However, a few issues. > > 1. My output is clashing with the system send info on "Hostname" and > filesystem logging. > 2. I want the "console-login" and "dtlogin" services to wait > indefinately until my service succeeds. > However after 3 attempt at executing the start method SMF marks my > service as failed and > proceeds to enable both dependent services. > I want the custom service to execute the start method once only > and never timeout, while waiting > for user input. > > Attached is my latest service manifest. > > Thanks, > > Mark > > > lianep at eng.sun.com wrote: >> Mark Duggan writes: >> >>> I'm working with a customer who has a security requirement to interrupt the >>> b >>> oot process >>> until a user has authenticated with a username and password. If the >>> authenti >>> cation fails >>> the system should shutdown. >>> I have seen in the documentation that it is strongly discouraged to require >>> u >>> ser input from >>> the console during the boot process, however, unfortunately that is a >>> non-neg >>> otiable customer >>> requirement. >>> This solution has been implemented in Linux but I now needs to be migrated >>> to >>> Solaris. >>> >>> Any help or suggestion would be appreciated. >>> >> >> It is discouraged, but entirely possible. :) We put in the warning to >> discourage software ISVs from putting in services which stop boot >> to expect configuration of their software. That's hostile to other >> software running on the system, and is a nasty surprise to people who >> didn't configure their systems explicitly to do so. We didn't take away >> the explicit choice from folks who want to deploy their systems that way. >> >> You'd essentially need to create an SMF service which redirects its >> input and output from the console, and make sure it doesn't conflict >> with any Solaris services which expect input from the console. >> >> That is, you need to make sure the customer's service isn't running at >> the same time as the sysid services, kdmconfig service (on x86), >> boot-archive service, console-login service, or dtlogin/gdm2 services. >> Where it would need to go depends on your customer's requirements >> for how early the boot process needs to be stopped (before network >> services? before filesystem mounts?). >> >> Let us know if we can help with the manifest. You can see the sysid >> services as an example. Essentially, they just do this in the methods >> (i.e. in /lib/svc/method/sysidtool-system): >> /usr/sbin/sysidsys > /dev/console < /dev/console 2>&1 >> >> liane >> >> > > > ------------------------------------------------------------------------ > > > <!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1"> > <!-- > > Service manifest for custom service "control_startup" > --> > > <service_bundle type='manifest' name='Custom:control_startup'> > > <service > name='system/control_startup' > type='service' > version='1'> > > <create_default_instance enabled='false' /> > > <single_instance /> > > <dependency > name='usr' > type='service' > grouping='require_all' > restart_on='none'> > <service_fmri value='svc:/system/filesystem/minimal' /> > </dependency> > > <dependency > name='loopback-network' > grouping='require_any' > restart_on='none' > type='service'> > <service_fmri value='svc:/network/loopback' /> > </dependency> > > <dependency > name='physical-network' > grouping='optional_all' > restart_on='none' > type='service'> > <service_fmri value='svc:/network/physical' /> > </dependency> > > <dependent > name='control_startup_console' > grouping='optional_all' > restart_on='none'> > <service_fmri value='svc:/system/console-login:default' /> > </dependent> > > > <dependent > name='control_startup_dtlogin' > grouping='optional_all' > restart_on='none'> > <service_fmri > value='svc:/application/graphical-login/dtlogin:default' /> > </dependent> > > <exec_method > type='method' > name='start' > exec='/var/tmp/console.sh' > timeout_seconds='60' /> > > <exec_method > type='method' > name='stop' > exec=':true' > timeout_seconds='60' /> > <property_group name='startd' type='framework'> > <propval name='duration' type='astring' > value='transient' /> > </property_group> > > <stability value='Unstable' /> > > <template> > <common_name> > <loctext xml:lang='C'> > custom boot script > </loctext> > </common_name> > > <documentation> > <manpage > title='control_startup' > section='1M' > manpath='/usr/share/man' /> > </documentation> > </template> > </service> > > </service_bundle> > > > ------------------------------------------------------------------------ > > _______________________________________________ > smf-discuss mailing list > smf-discuss at opensolaris.org -------------- next part -------------- A non-text attachment was scrubbed... Name: renaud.manus.vcf Type: text/x-vcard Size: 218 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/smf-discuss/attachments/20060224/94718a00/attachment.vcf>
