Upgrading to v1.8.8 stuck on Upgrading Roundcube to v.1.6.3

I woke up this morning to having an issue with Roundcube receiving emails, last night it was working fine. It said that it was unable to make some directories because some user was missing the +w permission. Well, I decided to start with sudo apt-get update && sudo apt-get upgrade then I would start doing some research online about the problem and got stuck on this in terminal. Any help with this?

Hello @Nguyjohnathon,

Do you have composer.phar in /var/lib/roundcube/? I’m asking because I’m pretty sure the command v-add-sys-roundcube is stuck because roundcube installation is asking interactively if you really want to run php composer.phar as root/super user and is waiting a yes or no but you can’t answer.

If that is the case you could kill the process v-add-sys-roundcube that must be stuck so the Hestia upgrade can continue and finalize the roundcube installation manually (roundcube 1.6.3 should be already installed, but maybe you want to finish the roundcube installation or reinstall it again manually just in case).

Cheers,
sahsanu

I had the same issue on on of my servers how ever I am sure we don’t call composer self …

Is not Hestia directly, composer.phar is called when v-add-sys-rouncube is executed during upgrade (this is the part):

$RC_INSTALL_DIR/bin/update.sh --version "$version" > /dev/null 2>&1

And that roundcube script executes composer.phar if it is found in /var/lib/roundcube/

if ($composer_bin = find_composer()) {
                echo "Executing " . $composer_bin . " to update dependencies...\n";
                echo system("$composer_bin update -d " . escapeshellarg(INSTALL_PATH) . " --no-dev", $exit_code);
            }
[...]
function find_composer()
{
    if (is_file(INSTALL_PATH . 'composer.phar')) {
        return 'php composer.phar';
    }

    foreach (['composer', 'composer.phar'] as $check_file) {
        $which = trim(system("which $check_file"));
        if (!empty($which)) {
            return $which;
        }
    }

    return null;
}
eris@web01:~$ which composer
/usr/bin/composer

Great …

1 Like

So composer.phar don’t even need to be present in the folder even /usr/bin/ is already enough

We need to fix this some how…

In my case I only had composer.phar in /var/lib/roundcube/ so I renamed it.

I was creating pre_install.sh and post_install.sh hook scripts to check whether roundcube has been updated and execute renamed composer.phar.original file and execute it to update using variable COMPOSER_ALLOW_SUPERUSER=1 to avoid the interactive question.

I don’t know whether it should be a good idea to modify v-add-sys-roundcube to add COMPOSER_ALLOW_SUPERUSER=1 before calling roundcube’s update.sh script:

COMPOSER_ALLOW_SUPERUSER=1 $RC_INSTALL_DIR/bin/update.sh --version "$version" > /dev/null 2>&1

Because, I’m afraid, a lot of users could have this issue. On the other side, it is supposed we should not use composer as root…

With 1.9.0 we could update the permissions so it runs under the new Hestia-web user and run the the update then…

Probably the best solution…

I agree, the best solution is to change the owner of /var/lib/roundcube/ to new Hestia-web user and execute the roundcube installation/upgrade with that user.

But till the new 1.9.0 version, I suppose we could fix it adding the composer variable before executing update.sh script or there will be a lot of stuck upgrades out there :frowning:

Yes …

Ok, let me open a PR

1 Like
1 Like

Great :wink:

1 Like

Merged…

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.