fatmcgav / fatmcgav-glassfish

Rewritten Glassfish module to improve functionality and support.
http://github.com/fatmcgav/fatmcgav-glassfish
GNU General Public License v3.0
6 stars 31 forks source link

Service restarted on every agent run #36

Closed nicklaslof closed 9 years ago

nicklaslof commented 10 years ago

I might have misunderstood the config but every time the puppet agent runs it stops the glassfish service and starts it again.

Running on Ubuntu 14.04 with 3.7.1 and Foreman.

Info: Applying configuration version '1412755942' Notice: /Stage[main]/Glassfish/Glassfish::Create_domain[artisol]/Glassfish::Create_service[artisol]/Exec[stop_artisol]/returns: executed successfully Notice: /Stage[main]/Glassfish/Glassfish::Create_domain[artisol]/Glassfish::Create_service[artisol]/Service[glassfish_artisol]/ensure: ensure changed 'stopped' to 'running' Info: /Stage[main]/Glassfish/Glassfish::Create_domain[artisol]/Glassfish::Create_service[artisol]/Service[glassfish_artisol]: Unscheduling refresh on Service[glassfish_artisol] Notice: Finished catalog run in 23.66 seconds

fatmcgav commented 10 years ago

@nicklaslof

Hmm, definitely shouldn't be doing that.

Are you able to run puppet agent with '--debug', and paste the output into a gist or pastebin link?

nicklaslof commented 10 years ago

ah yeah.. I see the reason here:

Debug: Executing 'service glassfish_artisol status && pgrep -f domains/artisol' Debug: /Stage[main]/Glassfish/Glassfish::Create_domain[artisol]/Glassfish::Create_service[artisol]/Exec[stop_artisol]/unless: Oracle Glassfish Java EE Application Server ver. 3.1.2.2 status: glassfish is not in the sudoers file. This incident will be reported.

nicklaslof commented 10 years ago

it's using the startscript to check the status which fails because the startscript tries to sudo to the glassfish user (which the script already is running as).

but the actual stop/start of the domain is using asadmin directly (without trying to sudo to the user)

fatmcgav commented 10 years ago

Ah, ok. If you give glassfish sudo permissions does it work as expected?

The behaviour due to having to stop the domain using asadmin when created to then start via the service resource.

I'll take a look see if there's a tweak I can make to improve.

Cheers Gavin On 8 Oct 2014 11:31, "Nicklas Löf" notifications@github.com wrote:

it's using the startscript to check the status which fails because the startscript tries to sudo to the glassfish user (which the script already is running as).

but the actual stop/start of the domain is using asadmin directly (without trying to sudo to the user)

— Reply to this email directly or view it on GitHub https://github.com/fatmcgav/fatmcgav-glassfish/issues/36#issuecomment-58338757 .

nicklaslof commented 10 years ago

yeah.. giving sudo rights to glassfish works.. not the optimal solution in the long run but will do for now.. thanks :)

fatmcgav commented 10 years ago

Agreed... I'll look at where that req for sudo permissions is coming from, as it's not explicit in my code...

fatmcgav commented 10 years ago

Ok, have tracked the issue to glassfish-init-domain-debian.erb. Looks like the Debain init script is using 'sudo' to start/stop the domain, hence the req for sudo permissions...

Would be happy to change the init script template if someone could suggest a modification that works? Unfortunately I'm not that familar with the nuances of Ubuntu, so not sure what the options are... On EL, the script uses 'daemon' to start the process: glassfish-init-domain-el.erb

dsantanu commented 10 years ago

If you want to run the Glassfish as "glassfish" user (as opposed to "root") then you do have to use sudo -u to start the service. I've my customize version of the init.d script, and I'm doing it like this:

sudo -u ${GFISH_USER} ${GFISH_HOME}/bin/asadmin start-domain > /dev/null 2>&1 &

I don't think I actually faced this prob. I'm [re]testing though.

fatmcgav commented 10 years ago

Ok, that mirrors the way the module sets up the Debian init script by using sudo to launch the service.

sudo -u $USER $GLASSFISHPATH/asadmin start-domain > /dev/null

But that relies on $USER having Sudo permissions...

It looks like upstart is a no-go, as there is no clean way of running Glassfish using it. So not sure what other option there is...

dsantanu commented 10 years ago

I think, I'm a bit confused here: Are you trying to run the init.d script as different user than "root"? I don't think you can do that. You need to run that script as "root" but the glassfish service will run as glassfish user in that case.

I've status in my init.d script, which returns 0 if running. So, in my install.pp I have this:

# Start Glassfish if not running
    exec {
        'start_gfish':
        command     => 'service glassfish start',
        unless      => 'service glassfish status',
        require     => [
                         File['initd_gfish'],
                         Exec['install_gfish'],
                       ];

        'restart_gfish':
        refresh     => 'service glassfish restart',
        command     => 'service glassfish restart',
        refreshonly => true,
        require     => [
                         File['initd_gfish'],
                         Exec['install_gfish'],
                       ];
    }

Which skips [re]starting glassfish if it's already running.

nicklaslof commented 10 years ago

yeah the problem is with the status check of the init script.. it fails because of the sudo rights which causes unless to be false:

count=sudo -u $USER ${GLASSFISHPATH}/asadmin list-domains | grep run | grep -v not | wc -l

it has to be sudo because of asadmin needs to read the asadmin password.

one way could be to skip the list-domains check and just rely on the second test which does a ps aux? I wonder if that could that give any false positives.

fatmcgav commented 10 years ago

Yeh, I think just running ps aux will give false positives aswell, as Glassfish looks the same whether it's running via service or via asadmin...

The service status check on EL behaves differently in that it won't return a success status if the domain has been started via asadmin. Not sure if we can achieve the same on Ubuntu?

Alternatively, the Glassfish group just needs to have a very specific set of sudo permissions granted to it to allow it to run asadmin...

dsantanu commented 9 years ago

this is my start(), stop() and status():

function start_gfish()
{
    if [ -f "$PIDFILE" ]; then
        echo -e "\n  Service: $(basename $0) already running [PID: $(cat ${PIDFILE})]!!\n"
        exit 4
    fi

    echo -e "\n  Starting $(basename $0)......"
    sudo -u $GFISH_USER ${GFISH_HOME}/bin/asadmin start-domain > /dev/null 2>&1 &
    echo ${!} > ${PIDFILE}

    sleep "${DIETIME}"s
    status_gfish
}

function stop_gfish()
{
    if [ -f "$PIDFILE" ]; then
        echo -e "\n  Stopping $(basename $0) [PID: $(cat ${PIDFILE})]....."
        sudo -u $GFISH_USER ${GFISH_HOME}/bin/asadmin stop-domain > /dev/null
        pkill java; pkill java
        rm $PIDFILE || return $?

        sleep "${DIETIME}"s
        status_gfish
    else
        echo -e "\n  Service: $(basename $0) arppears to stopped!!\n"
        exit 5
    fi
}

function status_gfish()
{
    if [ -f "$PIDFILE" ]; then
        echo -e "  Service: $(basename $0) is running [PID: $(cat ${PIDFILE})]!!\n"
        if [ $? -eq 0 ]; then
            return 0
        else
            rm $PIDFILE
        return 6
        fi
    else
        echo -e "  Service: $(basename $0) is not running!!\n"
        return 5
    fi
}

Not perfect in any way but working for me, so far.....

slamont commented 9 years ago

I've a fix for this in https://github.com/fatmcgav/fatmcgav-glassfish/pull/39

fatmcgav commented 9 years ago

Merged a fix in 841ed84f8e409debc9364760af1a4e139401f521