Wallace does not start/restart after yum update



  • Good Morning,
    After each update (at least the last three times) Wallace fails to start/restart which is leading into Mails are filling up the mailq

    This Morning this caused my Mails getting rejected after flush the mailq the first time.
    Mar 30 06:46:18 kolab postfix/smtpd[18467]: NOQUEUE: reject: RCPT from localhost[127.0.0.1]: 451 4.3.0 <users.mail@example.com>: Temporary lookup failure; from=<aussendung@blabla.at>

    New Mails are passing through, but about 50 Mails from the queue seem to be lost.

    The update seems to run without problems:

    ...
    
    roundcubemail-skin-chameleon.noarch 0:0.3.8-1.3.el7.kolab_16                                        roundcubemail-skin-chameleon-assets.noarch 0:0.3.8-1.3.el7.kolab_16
    roundcubemail-skin-chameleon-core.noarch 0:0.3.8-1.3.el7.kolab_16                                   roundcubemail-skin-larry.noarch 0:1.2-3.6.el7.kolab_16
    roundcubemail-skin-larry-assets.noarch 0:1.2-3.6.el7.kolab_16                                       wallace.noarch 0:0.8.1-2.3.el7.kolab_16
    
    Komplett!
    

    After looking a little bit back into the shell history the only thing i noticed running not like the other jobs:

      Aufräumen        : phantomjs-2.0.0-2.3.el7.kolab_16.x86_64                                                                                                                                         346/348
      Aufräumen        : libcalendaring-4.9.2-1.3.el7.kolab_16.x86_64                                                                                                                                    347/348
    /var/tmp/rpm-tmp.WwuY0G: Zeile 1: fg: Keine Job Steuerung in dieser Shell.
      Aufräumen        : cyrus-imapd-2.5.7-1.3.el7.kolab_16.x86_64                                                                                                                                       348/348
    /var/tmp/rpm-tmp.AlTKgW: Zeile 2: fg: Keine Job Steuerung in dieser Shell.
    warning: %postun(cyrus-imapd-2.5.7-1.3.el7.kolab_16.x86_64) scriptlet failed, exit status 1
    Non-fatal POSTUN scriptlet failure in rpm package cyrus-imapd-2.5.7-1.3.el7.kolab_16.x86_64
    etckeeper: post transaction commit
      Überprüfung läuft: roundcubemail-plugin-tasklist-skin-larry-assets-3.3-1.6.el7.kolab_16.noarch                                                                                                       1/348
      Überprüfung läuft: kolab-utils-3.1-17.4.el7.kolab_16.x86_64
    

    And this is what i found in /var/log/messages:

    Mar 29 22:17:29 kolab yum[17349]: Updated: wallace-0.8.1-2.3.el7.kolab_16.noarch
    Mar 29 22:17:29 kolab yum[17349]: Updated: kolab-server-0.8.1-2.3.el7.kolab_16.noarch
    Mar 29 22:17:29 kolab python: detected unhandled Python exception in '/usr/sbin/wallaced'
    Mar 29 22:17:30 kolab systemd: kolab-saslauthd.service: Supervising process 26207 which is not our child. We'll most likely not notice when it exits.
    Mar 29 22:17:30 kolab yum[17349]: Updated: kolab-saslauthd-0.8.1-2.3.el7.kolab_16.noarch
    Mar 29 22:17:30 kolab yum[17349]: Updated: postfix-kolab-0.8.1-2.3.el7.kolab_16.noarch
    Mar 29 22:17:31 kolab abrt-server: Package 'wallace' isn't signed with proper key
    Mar 29 22:17:31 kolab abrt-server: 'post-create' on '/var/spool/abrt/Python-2016-03-29-22:17:31-2921' exited with 1
    Mar 29 22:17:31 kolab abrt-server: Deleting problem directory '/var/spool/abrt/Python-2016-03-29-22:17:31-2921'
    Mar 29 22:17:32 kolab yum[17349]: Updated: cyrus-imapd-2.5.7-1.4.el7.kolab_16.x86_64
    Mar 29 22:17:33 kolab python: detected unhandled Python exception in '/usr/sbin/wallaced'
    Mar 29 22:17:34 kolab abrt-server: Not saving repeating crash in '/usr/sbin/wallaced'
    Mar 29 22:17:36 kolab systemd: wallace.service: main process exited, code=exited, status=1/FAILURE
    Mar 29 22:17:36 kolab kill: Usage:
    Mar 29 22:17:36 kolab kill: kill [options] <pid|name> [...]
    Mar 29 22:17:36 kolab kill: Options:
    Mar 29 22:17:36 kolab kill: -a, --all  do not restrict the name-to-pid conversion to processes
    Mar 29 22:17:36 kolab kill: with the same uid as the present process
    Mar 29 22:17:36 kolab systemd: wallace.service: control process exited, code=exited status=1
    Mar 29 22:17:36 kolab systemd: Unit wallace.service entered failed state.
    Mar 29 22:17:36 kolab systemd: wallace.service failed.
    Mar 29 22:17:36 kolab kill: -s, --signal <sig> send specified signal
    Mar 29 22:17:36 kolab kill: -q, --queue <sig>  use sigqueue(2) rather than kill(2)
    Mar 29 22:17:36 kolab kill: -p, --pid  print pids without signaling them
    Mar 29 22:17:36 kolab kill: -l, --list [=<signal>] list signal names, or convert one to a name
    Mar 29 22:17:36 kolab kill: -L, --tablelist signal names and numbers
    Mar 29 22:17:36 kolab kill: -h, --help display this help and exit
    Mar 29 22:17:36 kolab kill: -V, --version  output version information and exit
    Mar 29 22:17:36 kolab kill: For more details see kill(1).
    Mar 29 22:17:45 kolab systemd: Configuration file /usr/lib/systemd/system/auditd.service is marked world-inaccessible. This has no effect as configuration data is accessible via APIs without restrictions. Proceeding anyway.
    Mar 29 22:17:49 kolab systemd: Configuration file /usr/lib/systemd/system/auditd.service is marked world-inaccessible. This has no effect as configuration data is accessible via APIs without restrictions. Proceeding anyway.
    Mar 29 22:17:56 kolab guam: Exec: /opt/kolab_guam/erts-6.3/bin/erlexec  -noinput +Bd -boot /opt/kolab_guam/releases/0.7.2/kolab_guam -config /opt/kolab_guam/releases/0.7.2/sys.config -args_file /opt/kolab_guam/releases/0.7.2/vm.args -- foreground
    Mar 29 22:17:56 kolab guam: Root: /opt/kolab_guam


  • I see exactly the same thing. I find that a manual stop and start after each update works around this. But still quite worrying.


Log in to reply