Topic: qpsmtpd FAILED to start after update

[groyk]

Hi all

Just updated my SME10 box. after update I can't start qpsmtpd

Just checked "systemctl status qpsmtpd.service"

Code: [Select]

● qpsmtpd.service - qpsmtpd
   Loaded: loaded (/usr/lib/systemd/system/qpsmtpd.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Sat 2023-12-30 20:49:33 CET; 5min ago
  Process: 5894 ExecStartPre=/sbin/e-smith/service-status qpsmtpd (code=exited, status=9)

Dec 30 20:49:33 xxx.mydomain.com systemd[1]: Starting qpsmtpd...
Dec 30 20:49:33 xxx.mydomain.com service-status[5894]: qpsmtpd is not a service
Dec 30 20:49:33 xxx.mydomain.com systemd[1]: qpsmtpd.service: control process exited, code=exited status=9
Dec 30 20:49:33 xxx.mydomain.com systemd[1]: Failed to start qpsmtpd.
Dec 30 20:49:33 xxx.mydomain.com systemd[1]: Unit qpsmtpd.service entered failed state.
Dec 30 20:49:33 xxx.mydomain.com systemd[1]: qpsmtpd.service failed.


What else to check

[ReetP]

See Documenting and Logs.

https://forums.koozali.org/index.php/topic,54724.0.html

Particularly paste the output of these:

Code: [Select]

/sbin/e-smith/audittools/newrpms
/sbin/e-smith/audittools/templates
Be sure to remove any old templates.

[Jean-Philippe Pialasse]

service-status[5894]: qpsmtpd is not a service

means the entry qpsmtpd is missing from your configuration db, while it is a default entry. 
without that entry, the whole service can not be configured and therefore can not start.

This missing key in configuration db probably points to a bigger issue than only you qpsmtpd deamon…


what gives
ll /home/e-smith/db/configuration

I will most certainly need your backups.

[Jean-Philippe Pialasse]

and looking at https://forums.koozali.org/index.php/topic,55098.0.html

this seems not related to qpsmtpd update but rather playing with the db.

if you have did it using the db configuration or config commands you will see all old and new values/properties in the messages logs to repair that. 
hopping this is not bigger than that like the whole file deleted or corrupted by a manual intervention in it. 

also a signal-event post-upgrade; signal-event reboot might set back your db im a default working mode, but better would be to find a backup and understand what you did before issuing more commands.

[groyk]

means the entry qpsmtpd is missing from your configuration db, while it is a default entry. 
without that entry, the whole service can not be configured and therefore can not start.

This missing key in configuration db probably points to a bigger issue than only you qpsmtpd deamon…


what gives
ll /home/e-smith/db/configuration

I will most certainly need your backups.

ll /home/e-smith/db/configuration gives following output

-rw-r----- 1 root admin 14232 Dec 31 00:59 /home/e-smith/db/configuration

File is similar to my backup files for the last days.

[groyk]

See Documenting and Logs.

https://forums.koozali.org/index.php/topic,54724.0.html

Particularly paste the output of these:

Code: [Select]

/sbin/e-smith/audittools/newrpms
/sbin/e-smith/audittools/templates
Be sure to remove any old templates.

/sbin/e-smith/audittools/newrpms
Loaded plugins: fastestmirror, post-transaction-actions, priorities, smeserver
Loading mirror speeds from cached hostfile
 * base: mirrors.dotsrc.org
 * smeaddons: ibsgaarden.dk
 * smeos: ibsgaarden.dk
 * smeupdates: ibsgaarden.dk
 * updates: mirrors.dotsrc.org
Extra Packages
GeoIP.x86_64                       1.6.12-9.el7.sme    @smecontribs
GeoIP-GeoLite-data.noarch          2018.06-7.el7.sme   @smecontribs
GeoIP-GeoLite-data-extra.noarch    2018.06-7.el7.sme   @smecontribs
awstats.noarch                     7.8-3.el7           @smecontribs
dcp8112dncupswrapper.i386          3.0.0-1             @/dcp8112dncupswrapper-3.0.0-1.i386
dcp8112dnlpr.i386                  3.0.0-1             @/dcp8112dnlpr-3.0.0-1.i386
fail2ban-sendmail.noarch           0.11.2-3.el7        @smecontribs
fail2ban-server.noarch             0.11.2-3.el7        @smecontribs
hddtemp.x86_64                     0.3-0.31.beta15.el7 @smecontribs
openvpn.x86_64                     2.4.12-1.el7        @smecontribs
perl-Data-Validate-IP.noarch       0.27-13.el7         @smecontribs
perl-Geo-IP.x86_64                 1.45-1.of.el7       @smecontribs
perl-Unicode-IMAPUtf7.noarch       2.01-1.of.el7       @smecontribs
phpMyAdmin.noarch                  5.1.0-1.el7.sme     @smecontribs
pkcs11-helper.x86_64               1.11-3.el7          @smecontribs
smeserver-awstats.noarch           1.4-9.el7.sme       @smecontribs
smeserver-certificate.noarch       0.0.4-13.el7.sme    installed
smeserver-dhcpmanager.noarch       2.0.4-12.el7.sme    @smecontribs
smeserver-email-management.noarch  1.3-5.el7.sme       @smecontribs
smeserver-mailsorting.noarch       1.4-14.el7.sme      @smecontribs
smeserver-mailstats.noarch         1.1-17.el7.sme      @smecontribs
smeserver-mod_dav.noarch           1.1-8.el7.sme       installed
smeserver-openvpn-s2s.noarch       0.2-19.el7.sme      @smecontribs
smeserver-phpmyadmin.noarch        4.0.10.2-14.el7.sme @smetest
smeserver-remoteuseraccess.noarch  1.3-6.el7.sme       @smecontribs
smeserver-rsync-backup2disk.noarch 0.0.2-3             @smecontribs
smeserver-smeadmin.noarch          1.6-10.el7.sme      installed
smeserver-tw-logonscript.noarch    1.5-11.el7.sme      @smecontribs
smeserver-vacation.noarch          1.1-34.el7.sme      @smecontribs
smeserver-wbl.noarch               0.5.0-7.el7.sme     @smecontribs
smeserver-webhosting.noarch        0.0.9-17.el7.sme    @smecontribs
wol.x86_64                         0.7.1-23.el7        @epel


/sbin/e-smith/audittools/templates
/etc/e-smith/templates-custom/etc/smb.conf/50homes: MANUALLY_ADDED, OVERRIDE
/etc/e-smith/templates-custom/etc/smb.conf/ibays/10recyclebin: MANUALLY_ADDED, OVERRIDE
/etc/e-smith/templates-custom/etc/php5/php.ini/30ErrorHandling: MANUALLY_ADDED, ADDITION
/etc/e-smith/templates-custom/etc/php.ini/12phptmpfolder: MANUALLY_ADDED, ADDITION
/etc/e-smith/templates-custom/etc/php.ini/30ErrorHandling: MANUALLY_ADDED, OVERRIDE
/etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/50AddSecureIbayFolder: MANUALLY_ADDED, ADDITION
/etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts/60redir-pgadmin: MANUALLY_ADDED, ADDITION
/etc/e-smith/templates-custom/etc/e-smith/pam/accounts.deny/10passwordRequired: MANUALLY_ADDED, OVERRIDE
/etc/e-smith/templates-custom/etc/atalk/papd.conf/20printers: MANUALLY_ADDED, ADDITION
/etc/e-smith/templates-custom/etc/atalk/papd.conf/10intro: MANUALLY_ADDED, ADDITION
/etc/e-smith/templates-custom/etc/crontab/custom.cron: MANUALLY_ADDED, ADDITION
/etc/e-smith/templates-custom/var/lib/pgsql/data/pg_hba.conf: MANUALLY_ADDED, ADDITION
/etc/e-smith/templates-custom/var/lib/pgsql/data/postgresql.conf: MANUALLY_ADDED, ADDITION

[ReetP]

Look for your old config changes with something like this:

grep configuration /var/log/messages*

grep event /var/log/messages*

grep -i processing /var/log/messages*

If you are lucky you may see the entire key that has been deleted which you can then restore.

You may also want to consider what other damage has been done to your install.

How did you do your upgrade?

You should also check that your manual templates are still relevant, particularly with httpd/php templates.

[Jean-Philippe Pialasse]

this one will indeed show OLD NEW values for the qpsmtpd field if you used db or config command line tool.

grep configuration /var/log/messages*

this should be the important part blocking you:

config show qpsmtpd

[groyk]

this one will indeed show OLD NEW values for the qpsmtpd field if you used db or config command line tool.

grep configuration /var/log/messages*

this should be the important part blocking you:

config show qpsmtpd

Thank you both for your help. I found the problem
 I ran grep configuration /var/log/messages* and found that one thing has changed! properly because of my missing arround

qpsmtpd=service was changed to qpsmtpd=configuration

changed it back in the DB and everything seems to run now

[ReetP]

Good news. Be careful

Go back and check your custom templates and make sure they are relevant on v10. Lots changed with httpd/php !!

[Jean-Philippe Pialasse]

Good news. Be careful

Go back and check your custom templates and make sure they are relevant on v10. Lots changed with httpd/php !!

I second that.  and this is not only because it seems to work or does not seem to prevent anything to work, does not means it is  :
- secure ( pre httpd 2.4 syntax might interfere with new syntax. )
- indeed working, you might need to investigate more. 

i highly suggest to remove all snd only put back those actually preventing you to obtain what you want.