normally we have backup of sogo database I think
Nope. I deleted it altogether.
I can see in sope.spec and sogo.spec : AutoReqProv: off
But in the doc and my other spec I can read : AutoReqProv: no
Indeed we could try to fix for the other version, but I bet my trouser that it won’t fix your issue.
For libwbxml need to check
I presume you mean you deleted it from disk, this does nont mean mariadb (mysql) “knows” it is gone.
It’d been a while since there was a need to “drop” a db from mysql. It is not on my finger tips, something like:
EDIT: (see below)
mysql -e "drop database sogo;"
not sure about the above (@ support_team help!) , however you manage to drop the db
you may run:
signal-event nethserver-sogo-update
well the build failed
Let me investigate…
Executing(%check): /bin/sh -e /var/tmp/rpm-tmp.5VUYC4
+ umask 022
+ cd /builddir/build/BUILD
+ cd libwbxml-0.11.6
+ cd x86_64-redhat-linux-gnu
+ ctest
*********************************
No test configuration file found!
*********************************
ctest version 2.8.12.2
Usage
You have some missing docs also to remove, but this is the worst error I think
it a long while ago (1y and 8m) sogo 4.0.1, can not remember how… It did build though…
You may put a project card in nethforge project and assign me.
do you think my recollection of dropping sogo the db adds up?
That should work but defining the conf file should not be necessary and with -e
you get a one liner:
mysql -e "drop database sogo;"
I should have been more specific. I dropped the database. The user and the DB are created but not the tables. That’s all I can say.
Do you mean that the version provided by nethforge is not the latest ? Then it could be the bug I mentioned earlier that triggers. It is said to be fixed in 4.0.8, maybe you could provide a new version ? Can I help ?
Thank you anyway !
we have a new version of SOGo, I build it, thank to mark who provides a new spec file
Sorry we confuse you: the libwbxml
has nothing to do with your problem. It’s a build requirement statical linked in Sogo at build time. It is not installed. going trough the SPEC we use to build Sogo I remembered we should try to build against a newer version.
It’s also hard to reproduce: install sogo 3.2.x use it, remove it and install Sogo 4.2.0
probably a ownership isseu, let me think about that…
EDIT:
does systemctl status sogo
give clue’s ?
Who owns /var/log/sogo
? should be sogo:sogo
Who owns /etc/sogo/sogo.conf
? should be root:sogo
# systemctl restart sogod
Job for sogod.service failed because a timeout was exceeded. See "systemctl status sogod.service" and "journalctl -xe" for details.
[root@cloud ~]# systemctl status sogod
● sogod.service - SOGo is a groupware server
Loaded: loaded (/usr/lib/systemd/system/sogod.service; enabled; vendor preset: disabled)
Active: failed (Result: timeout) since Fri 2020-05-22 09:01:34 CEST; 50s ago
Process: 22285 ExecStart=/usr/sbin/sogod -WOWorkersCount ${PREFORK} -WOPidFile /var/run/sogo/sogo.pid -WOLogFile /var/log/sogo/sogo.log (code=killed, signal=TERM)
May 22 09:00:04 cloud.gaillet.be systemd[1]: Starting SOGo is a groupware server...
May 22 09:01:34 cloud.gaillet.be systemd[1]: sogod.service start operation timed out. Terminating.
May 22 09:01:34 cloud.gaillet.be systemd[1]: Failed to start SOGo is a groupware server.
May 22 09:01:34 cloud.gaillet.be systemd[1]: Unit sogod.service entered failed state.
May 22 09:01:34 cloud.gaillet.be systemd[1]: sogod.service failed.
# ls -lai /var/log/sogo
total 60
3411207 drwx------. 2 sogo sogo 4096 Jan 23 17:09 .
3408261 drwxr-xr-x. 25 root root 24576 May 21 07:11 ..
3411206 -rw-r--r--. 1 olefy olefy 0 Jun 9 2019 sogo.log
# ls -lai /etc/sogo/sogo.conf
2622854 -rw-r----- 1 root sogo 4107 May 21 12:05 /etc/sogo/sogo.conf
That may be a good track however. I rm -rf the log/sogo directory and it did not recreate even after a signal-event nethserver-sogo-update.
olefy is wrong, but how come?
try chown -R sogo:sogo /var/log/sogo
you may edit /etc/sogo/sogo.conf and remove the marked-out (//) of some debug settings:
/* 80 Debug */
//SOGoDebugRequests = YES;
//SoDebugBaseURL = YES;
//ImapDebugEnabled = YES;
//LDAPDebugEnabled = YES;
//PGDebugEnabled = YES;
//MySQL4DebugEnabled = YES;
//SOGoUIxDebugEnabled = YES;
//WODontZipResponse = YES;
//SOGoEASDebugEnabled = YES;
NOTE: this is a templated conf file, changes will be lost by a update event
and restart sogod, it should write some stuff to the log
Still nothing in /var/log/sogo, even with debug. That’s really strange. Don’t know how that olefy user came there either.
That olefy thing is really weird.
# tail /etc/passwd
olefy:x:983:978::/home/olefy:/bin/bash
sogo:x:982:977:SOGo daemon:/var/lib/sogo:/sbin/nologin
Those are the two last users created on my system.
Also :
# find / -group olefy
/var/lib/sogo/GNUstep
/var/lib/sogo/GNUstep/Defaults
/var/lib/sogo/GNUstep/Defaults/.lck
/var/lib/sogo/backups
/var/lib/sogo/backups/sogo-2019-05-27_0030
/var/lib/sogo/backups/sogo-2019-05-27_0030/admin
/var/lib/sogo/backups/sogo-2019-05-27_0030/anne-lise
/var/lib/sogo/backups/sogo-2019-05-27_0030/matthieu
(...)
/proc/747/map_files/7fa569682000-7fa569686000
/proc/747/map_files/7fa569686000-7fa569688000
/proc/747/map_files/7fa56968d000-7fa56978e000
(...)
Update : I did my own version of @stephdl’s bazooka :
find / -name "*sogo*" -exec rm -rf {} +
Then reinstalled. The service starts !! Now there is still a 503 service unavailable problem but I guess that should be solved easily.
So there was probably something wrong with access rights and that olefy user. Thanks @mark_nl and all for brainstorming with me
Glad did you solved, @pagaille. I should anyway advice to backup before trying to do the same thing! Even a nice snapshot could be a great idea.
True @pike. However I’m not sure that in this case it would have helped much since it looks like a mixup with access rights.
Sogo was uninstalled for one year, there have been a lot of changes meanwhile. Moreover, since I use it only as a frontend for the imap server I didn’t really care about any content or configuration.