Thanks, Christine.

-- Mike

On 02/06/13 08:24, Christine Tran wrote:
The tag you want is optional_all, but I have no idea whether the designer of picld intends for the system to be so dependent on it that if picld is not running the system goes to single-user. That's not what the block above says anyway, it says milestone single-user comprises picld. Is the user saying if picld is disabled, a reboot or next boot takes it up to single-user, or if at normal multi-user-server, picld is disabled the system automatically takes itself down to single-user? In my experience this has not happened, a system changing milestone state in response to a dependency. I'm not aware that milestone is "active".

CT


On Wed, Feb 6, 2013 at 10:26 AM, Michael Bergknoff <[email protected] <mailto:[email protected]>> wrote:

    On 02/28/12 15:13, Antonello Cruz wrote:

        On 02/28/12 09:02, Michael Bergknoff wrote:

            Hi,

            Can somebody verify that this is the correct way to start
            a service in
            single user mode?

            http://esp.west.sun.com/~mbergkno/7146867-files/s11u1/webrev/
            <http://esp.west.sun.com/%7Embergkno/7146867-files/s11u1/webrev/>

            Seems to work fine , just looking for a reviewer.

        If what you are looking for is to have

            svc:/system/picl:default

        running when you boot single-user your changes are good.


        Antonello


    Hi All,

    The change above made the single-user milestone dependent on picld.
    From picl.xml:

    <dependent
                    name='picl_single-user'
                    grouping='require_all'
                    restart_on='none'>
    <service_fmri value='svc:/milestone/single-user' />
    </dependent>

    I got a complaint from a customer that when picld is disabled the
    system boots to single-user. Is there something (like an optional
    tag) missing to prevent this or is that required behavior for
    services that should run in single-user?

    -- Mike
    _______________________________________________
    smf-discuss mailing list
    [email protected] <mailto:[email protected]>



_______________________________________________
smf-discuss mailing list
[email protected]

Reply via email to