SOGo does not start - segfault error 6 in libgnustep-base

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;"

mysql --defaults-file=/root/.my.cnf drop database sogo; exit

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

1 Like

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. :grinning:

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;"

2 Likes

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

1 Like
# 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

1 Like

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 :blush:

1 Like

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.