search

obiba / rock

R server with a REST API
GNU General Public License v3.0
3 stars 1 forks source link

[1.0.3] Unable to start rock #2

Closed tuxmaster5000 closed 3 years ago

tuxmaster5000 commented 3 years ago

Under CentOS7 rock fails to start with: cat /var/log/rock/stdout.log Error: Could not find or load main class org.obiba.rock.Application

tuxmaster5000 commented 3 years ago

When using /usr/share/rock/bin/rock.sh And when using "systemctl start rock" no process will running.

ymarcon commented 3 years ago

Please try to apply the same fix on rock.sh as in https://github.com/obiba/rock/commit/01cf528a750bdfd6ea9744041dfda6fac361fcd8 and let me know if it works now.

tuxmaster5000 commented 3 years ago

I build an fix for it, because the init.d start up is dead on current RHEL systems. RHEL6 is EOL an RHEL7 and newer use systemd instant. As far my service file is ready, I will append it.

tuxmaster5000 commented 3 years ago

Here is the final systemd script needed for modern RHEL aka CentOS systems:

[Unit] Description=Opal Rock service

[Service] WorkingDirectory=/var/lib/rock EnvironmentFile=/etc/default/rock User=rock LimitNOFILE=16384 ExecStart=/usr/bin/java $JAVA_ARGS -cp "${ROCK_HOME}/conf:${ROCK_DIST}/lib/*" -DROCK_HOME=$ROCK_HOME -DROCK_DIST=$ROCK_DIST -DROCK_LOG=$ROCK_LOG org.springframework.boot.loader.JarLauncher $ROCK_ARGS

[Install] WantedBy=network-online.target

ymarcon commented 3 years ago

I guess that rock.sh works with the fix I provided, right?

tuxmaster5000 commented 3 years ago

Oh one type here: is mus be: ExecStart=/usr/bin/java $JAVA_ARGS -cp "${ROCK_HOME}/conf:${ROCK_DIST}/lib/*" -DROCK_HOME=${ROCK_HOME} -DROCK_DIST=${ROCK_DIST} -DROCK_LOG=${ROCK_LOG} org.springframework.boot.loader.JarLauncher $ROCK_ARGS

tuxmaster5000 commented 3 years ago

Yes your commit will fix it.

ymarcon commented 3 years ago

Thanks for the systemd script, it works on ubuntu as well. Need to figure out how to migrate from init.d script to the systemd one in the package installation process.

tuxmaster5000 commented 3 years ago

For RHEL, simple remove the exchange the script and call systemctl daemon-reload in the %post section And then use the systemd macros in the rpm spec file. See here as an example: https://src.fedoraproject.org/rpms/httpd/blob/f34/f/httpd.spec

ymarcon commented 3 years ago

Call required to make systemd switch from an init.d script to the systemd one: systemctl daemon-reload

ymarcon commented 3 years ago

Could you try in CentOS if this RPM package works? Both for the case of an upgrade and a clean install. https://github.com/obiba/rock/releases/tag/1.1.0-beta That would be very helpful, thanks.

tuxmaster5000 commented 3 years ago

Yes I will try it on Monday and give you the feedback.

ymarcon commented 3 years ago

Thanks. Just tried on debian environment and it works.

ymarcon commented 3 years ago

FYI I have just rebuilt the 1.1.0-beta packages, to enable service start on system boot.

tuxmaster5000 commented 3 years ago

An clean install will work, but an update will fails. After the update of the package the status will fails with:

systemctl status rock
Failed to get properties: Access denied

Also the old init.d files are not removed. I think the pre script of the package must call "chkconfig --del rock" before the new files are installed,

ymarcon commented 3 years ago

Thanks for the test, this is very helpful! I have added the chkconfig trick. I am not sure for the systemctl issue. Some people reported some systemd issues (but this was a long time ago). Anyway I have made a new pre-release https://github.com/obiba/rock/releases/tag/1.1.0-beta2 if you could give it a try...

tuxmaster5000 commented 3 years ago

Now the old init symlinks are removed this is fine (comes from chkconfig) But the systemctl status rock call fails with the same error :( This can fixed with an "systemctl daemon-reload" call. But then I seen, that the service was not restarted with the package update. Only after an additional "systemctl restart rock" the current version of it will run. And then the new one will run, but the logs are going into /var/lib/rock/logs :( instant of /var/log/rocks

ymarcon commented 3 years ago

Please try this one https://github.com/obiba/rock/releases/tag/1.1.0-beta3 in which preinstall script ensures the service is stopped.

Regarding the logs, /var/lib/rock/logs is supposed to be a symlink to /var/log/rock

tuxmaster5000 commented 3 years ago

Now:

ymarcon commented 3 years ago

Obviously the postinstall script is not executed because this is the one that does the missing systemctl calls and the logs symlink.

tuxmaster5000 commented 3 years ago

Where can I find the spec file for the rpm build? Then I can take an look into it.

ymarcon commented 3 years ago

Some scriptlet doc: https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/

The RPM package is built using the RPM maven plugin: https://github.com/obiba/rock/blob/systemd/pom.xml#L69-L176 https://www.mojohaus.org/rpm-maven-plugin/adv-params.html#Scripts

tuxmaster5000 commented 3 years ago

Oh, then I can't help, because I only build rpm packages direct from spec file, which is the official way. And it looks like mave have its own way. :( I think this will be the reason why some scripts fails. Does maven create an temporary spec file or an srpm file? If yes, please attach it, so that I can "debug" it.

ymarcon commented 3 years ago

I cannot found srpm file but I have the spec file (renamed with .txt for github upload).

rock.spec.txt

tuxmaster5000 commented 3 years ago

This will helps.

The first problem is in line 119. It will not work, because in the old package /var/lib/rock/logs is an directory, So first the old files must be moved, then the directory must be removed. After that the symlink can be created.

The case switch of line 164 are not needed, because in both valid scenarios the same function is called.

On line 58 the if is also unneeded I think. An simple "systemctl stop rock" is enough, because the call is forward to the init.d subsystem in the old case. In line 73, an "systemctl daemon-reload" are needed, to tell systemd to clean up before the sysetmd service file will be placed.

ymarcon commented 3 years ago

Thanks, here is the new spec: rock.spec.txt

and the corresponding RPM: https://github.com/obiba/rock/releases/tag/1.1.0-beta4

tuxmaster5000 commented 3 years ago

Now after the update the server is stopped, when it was running before, but the systemd system is now happy. But the restart after the update will not work.

The mkdir /var/log/rock is not necessary, because the directory comes the the package:

less rock-1.1.0-beta4_1.noarch.rpm
Name        : rock
Version     : 1.1.0
Release     : beta4_1
Architecture: noarch
Install Date: (not installed)
Group       : Applications/Engineering
Size        : 30785586
License     : GPLv3
Signature   : (none)
Source RPM  : rock-1.1.0-beta4_1.src.rpm
Build Date  : Di 08 Jun 2021 15:02:44 CEST
Build Host  : travis-job-762f3bee-7e14-44c9-b1c0-5246a0f4936a
Relocations : /usr/share 
Packager    : OBiBa
Summary     : rock
Description :
R server controller with REST API
-rw-r--r--    1 root    root                      716 Jun  8 15:02 /etc/default/rock
drw-r-----    2 rock    adm                         0 Jun  8 15:02 /etc/rock
-rw-r-----    1 rock    adm                       498 Jun  8 15:01 /etc/rock/Rprofile.R
-rw-r-----    1 rock    adm                       498 Jun  8 15:01 /etc/rock/Rserv.conf
-rw-r-----    1 rock    adm                      1220 Jun  8 15:01 /etc/rock/application.yml
-rw-r-----    1 rock    adm                      1320 Jun  8 15:01 /etc/rock/logback.xml
-rw-r-----    1 rock    adm                       990 Jun  8 15:01 /etc/rock/system.info.R
-rw-r--r--    1 root    root                      425 Jun  8 15:01 /lib/systemd/system/rock.service
drwxr-----    2 rock    adm                         0 Jun  8 15:02 /tmp/rock
drwxr-xr-x    2 root    root                        0 Jun  8 15:02 /usr/share/rock-1.1.0-beta4/bin
-rwxr-xr-x    1 root    root                     2013 Jun  8 15:01 /usr/share/rock-1.1.0-beta4/bin/rock.sh
-rwxr-xr-x    1 root    root                       58 Jun  8 15:01 /usr/share/rock-1.1.0-beta4/bin/update.sh
drwxr-xr-x    2 root    root                        0 Jun  8 15:02 /usr/share/rock-1.1.0-beta4/lib
-rwxr-xr-x    1 root    root                 30777848 Jun  8 15:02 /usr/share/rock-1.1.0-beta4/lib/rock-1.1.0-beta4.jar
drwxr-----    2 rock    adm                         0 Jun  8 15:02 /var/lib/rock
drwxr-----    2 rock    adm                         0 Jun  8 15:02 /var/log/rock

When I look in the less output I seen the next big problem. /tmp/rock is very bad idea, because /tmp is an tmps on modern systems. So when the application stores big data here then /var/tmp/ must be used. And the second tmp problem is, that an tmpfiles.d config file is needed in both cases. (/var/tmp, /tmp) See https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html

The symlink for the log will fails, because the mv call fails when the source directory is empty. So the mv/ln section must be something like this:

if [ ! -L "$LOG_DIR_OLD" ]; then
  if [ -n "$(ls -A $LOG_DIR_OLD)" ]; then
    mv $LOG_DIR_OLD/* $LOG_DIR
  fi
  rm -rf $LOG_DIR_OLD
  ln -s $LOG_DIR $LOG_DIR_OLD
fi

Line 107 to 109 must be declared in the file section of the spec file. Doing this in the post section is an very bad idea, because it is complete agains the rpm design.

I can create an clean spec file, but I have no idea if you can add this to build process, because it will use many macros which are only functional when building the rpm package on an system using mock. (the clean way to build rpm packages, from spec files and srpm packages.)

ymarcon commented 3 years ago

There are some legacy code I am afraid... /tmp/rock was for the daemon based, not relevant with systemd, it has been cleaned. Now the RPM packaging takes care of the base folders layout, owner and rights.

Last pre-release: https://github.com/obiba/rock/releases/tag/1.1.0-beta6

Specs: rock.spec.txt

tuxmaster5000 commented 3 years ago

Tested again. But the same error as on https://github.com/obiba/rock/issues/2#issuecomment-857418404 I will try to build an spec file and send it to you.

tuxmaster5000 commented 3 years ago

Now I have an working solution, but I don't know how you can build this in your build environment, because my was only tested using mock. (The RedHat/Fedora way to build rpm packages) So I have attached the srpm file. The both "trans" sections of the spec file can be removed in an later one, because the are only needed for the migration.

tuxmaster5000 commented 3 years ago

Because github will not allow big files, I only have attached the relevant part of it. X.zip

ymarcon commented 3 years ago

Thanks, I will try that. One question: all those keywords %{_sharedstatedir}, %{name} etc. should be written as-is in the scriptlets?

tuxmaster5000 commented 3 years ago

yes, because this are macros, which make the life simpler :)

ymarcon commented 3 years ago

I have added your scriptlets, not sure of the result given the build tool that is used. https://github.com/obiba/rock/releases/tag/1.1.0-beta1

tuxmaster5000 commented 3 years ago

No, the result will be different. I think your build environment will not use the the same macros as it is used default by RedHat/Fedora one. %{_sharedstatedir} will be /usr/com in your environment. And the %systemd_post, %systemd_postun_with_restart macros are not resolved. :(

ymarcon commented 3 years ago

Is there a page that describes those macros?

tuxmaster5000 commented 3 years ago

Only partial: https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#Systemd https://docs.fedoraproject.org/en-US/packaging-guidelines/RPMMacros/ For the systemd macros I have added the source file for it. macros.systemd.txt

ymarcon commented 3 years ago

I have developped the macros. Please give it a try: https://github.com/obiba/rock/releases/tag/1.1.0-beta

tuxmaster5000 commented 3 years ago

Hi some macros are not the same as needed. %systemd_post: in my package it is resolved to:

if [ $1 -eq 1 ] ; then 
        # Initial installation 
        systemctl preset rock.service >/dev/null 2>&1 || : 
fi

in yours: systemctl --no-reload preset rock.service

%preun: my:

if [ $1 -eq 0 ] ; then 
        # Package removal, not upgrade 
        systemctl --no-reload disable rock.service > /dev/null 2>&1 || : 
        systemctl stop rock.service > /dev/null 2>&1 || : 
fi

yours:

systemctl preset rock.service
systemctl start rock.service

%postun: my:

systemctl daemon-reload >/dev/null 2>&1 || : 
if [ $1 -ge 1 ] ; then 
        # Package upgrade, not uninstall 
        systemctl try-restart rock.service >/dev/null 2>&1 || : 
fi

yours: systemctl try-restart rock.service

ymarcon commented 3 years ago

Sorry about that, this is really painful, it is like coding in the dark. Please try this new build: https://github.com/obiba/rock/releases/tag/1.1.0-beta

tuxmaster5000 commented 3 years ago

No problem, I know,it is every time an real problem, when you build software using not the system own work flow. Now the script part of package looks like mine. :)

ymarcon commented 3 years ago

Does it work? when:

tuxmaster5000 commented 3 years ago

I will check it on Monday.

tuxmaster5000 commented 3 years ago

The fresh install will fails. because useradd must be called with an lower -c instant of -C for the command. Please change it, then I can try it again.

ymarcon commented 3 years ago

Ok. please try again: https://github.com/obiba/rock/releases/tag/1.1.0-beta

tuxmaster5000 commented 3 years ago

Now the user create will work. Here the next errors:

ymarcon commented 3 years ago

Please try again: https://github.com/obiba/rock/releases/tag/1.1.0-beta

tuxmaster5000 commented 3 years ago

Hm, now the workong part is missing and the fixed are not included.

tuxmaster5000 commented 3 years ago

Here the current spec file, of my working version. Test for update an clean install. rock.spec.gz

ymarcon commented 3 years ago

I have installed a centos7 box and was able to test install and upgrade. I consider 1.0.3 RPM package broken. Installing and upgrading systemd-compliant new packages will work as expected (minor issue: centos7 is really old and does not have systemd 236+, so process stderr and stdout redirect to file is not supported).