systemctl: relocation error: systemctl: symbol internal_hashmap_size version SD_SHARED not defined in file with link time reference

  • Hey,

    Not i-mscp related but looks like it's something new because I did not find any info related on the web.

    All my Ubuntu 18.04LTS that are runing i-mscp are stuck with this error when I try to restart any service. Any suggestions on how can I fix this. It looks like it's something serious...

    1. systemctl: relocation error: systemctl: symbol internal_hashmap_size version SD_SHARED not defined in file with link time reference


    Edited once, last by Delta04 ().

  • Yeah, didn't find a lot of informations so far.

    Only thing I saw, someone who tried to update from 18.04 to 18.10 and break everything (no real solution) and some other who might have got failed normal updates (but this was, mostly, on RedHat/CentOS :D ).

    All in all, the only advise I could read there was to check no updates were pending or in a fail state.

  • I found one that is working. I wonder if the problem are'nt those new versions. Weird is that I definately did not upgrade them manually. I guess Python3 cound be the problem here, on some systems ....

    root@csrv:~# apt-get update && apt-get upgrade

    Hit:1 bionic InRelease

    Hit:2 bionic InRelease

    Hit:3 bionic-updates InRelease

    Hit:4 bionic-backports InRelease

    Hit:5 bionic-security InRelease

    Reading package lists... Done

    Reading package lists... Done

    Building dependency tree

    Reading state information... Done

    Calculating upgrade... Done

    The following packages have been kept back:

    python3-update-manager ubuntu-advantage-tools update-manager-core

    The following packages will be upgraded:

    base-files distro-info-data motd-news-config update-notifier-common

    4 upgraded, 0 newly installed, 0 to remove and 3 not upgraded.

    Need to get 242 kB of archives.

    After this operation, 1,024 B of additional disk space will be used.

    Do you want to continue? [Y/n]

    Edited once, last by Delta04 ().

  • Update: I restored an backup created on 3 of May and everything is working fine. Weird...

  • I know that on recent Ubuntu releases (20+ at least), there is this package installed : unattended-upgrades

    This install "harmless" update without letting you know by default.

    Well, harmless, it depend, as this update Docker even with containers running (so they crash and reboot once updated :D )

    I had to remove this package to ensure I didn't run into that anymore, maybe something to look on your side ? :)

  • Exactly my thought, I did not such upgrades during 5 may and 7may, the only "person" who could do upgrades is that thing unattended-upgrades. By default it just apply security upgrades but who knows what happened... After this surprise,

    1. sudo systemctl stop unattended-upgrades && sudo systemctl disable unattended-upgrades && sudo dpkg-reconfigure unattended-upgrades

    I'm still digging here. Be right back with updates as soon as I have them. :)

  • Well, I found the solution. Neither reboot or power off command is not working so stoping the server from the button, like aggressively power it off and start it again solve the problem. I have no idea why this is happening. Thanks Athar for support! :)