2

I modified unit files according to your post:

[Unit]
Description=My Portal Service
After=network.target

[Service]
SyslogIdentifier=my-portal
Environment=SERVICE_NAME=my-portal
Environment=PATH_TO_TARGET=/opt/apps/egp/stage/my-portal/target
ExecStart=/usr/bin/env java -jar ${PATH_TO_TARGET}/${SERVICE_NAME}.jar server ${PATH_TO_TARGET}/${SERVICE_NAME}.yml

[Install]
WantedBy=multi-user.target

I also run command:

systemctl daemon-reload

to reload systemd manager configuration.

All is working fine - I can successfully start, stop and see the status of the service using:

 systemctl start my-portal
 systemctl status my-portal -l
 systemctl stop my-portal

And after I fix the problem with Java env variables - I will run this command:

systemctl enable service-name

to start service (services- 5 in total) on boot.

The problem I have is setting Java env variables. I tried various versions: adding them in .bash_profile and using source command,then writing Java env in separate javaenv.sh file in /etc/profile.d folder:

export JAVA_HOME=/opt/jdk1.7.0_80
export PATH=/opt/jdk1.7.0_80/bin:$PATH

Gave permission:

chmod +x /etc/profile.d/javaenv.sh

and modified unit file adding ${JAVA_HOME}/bin in ExecStart line... It does not finding Java. I had the same problem before, when I was using sh scripts getting the error:

nohup: failed to run command ‘java’: No such file or directory

I read many posts on that issue - but cannot find the solution to set Java variables in one place and use them in other units or script files as ${JAVA_HOME} variables.

Where to set Java env variables to be used in various places permanently without logging?

Improve this question
2
  • 1
    Solved. I added Java env (JAVA_HOME and $JAVA_HOME/bin) to to /etc/environment file and added sym link to my java in usr/bin: ln -s /opt/jdk1.7.0_80/bin/java /usr/bin/java
    – ganna07
    May 26, 2018 at 15:21
  • sudo ln -s $(which java) /usr/bin/java
    – abdul rashid
    Dec 25, 2019 at 13:15

2 Answers 2

Reset to default
3

.INI file syntax basics

[Unit]
Description = My Portal Service
After network.target = my-portal.service

In the section Unit the key is supposed to be After and the value is (for example) network.target my-portal.service. You have a key of After network.target and a value my-portal.service. That key means nothing to systemd, as the message told you.

Outright systemd House of Horror stuff

Making a service ordered to start after itself is ludicrous. But that's just the tip of the iceberg here.

Type = forking
ExecStart = /usr/local/bin/my-portal.sh start
ExecStop = /usr/local/bin/my-portal.sh stop
ExecReload = /usr/local/bin/my-portal.sh reload
…
PATH_TO_LOG="/var/log/egp"
…
PID_PATH_NAME=/var/run/${SERVICE_NAME}-pid
nohup … >> ${PATH_TO_LOG}/${SERVICE_NAME}.out 2>&1&

All of this is just the classic pattern, strangely predominant with Java, of erecting a foolish mess of wholly unnecessary and erroneous scaffolding.

You don't need the shell script at all. You certainly don't need the rickety and dangerous PID file mechanism that it tries to employ. Nor do you need a hand-rolled logging mechanism that relies upon a rickety logrotate/newsyslog mechanism, and cannot prevent your disc volume from filling up with log output (written by a process with superuser privileges, so it will even eat into the superuser-reserved emergency disc space) in many cases.

Use the service manager features that exist:

#/etc/systemd/system/my-portal.service
[Unit]
Description=My Portal Service
Documentation=https://unix.stackexchange.com/a/434726/5132
After=network.target

[Service]
SyslogIdentifier=my-service
Environment=SERVICE_NAME=my-service
Environment=PATH_TO_TARGET="/opt/apps/egp/stage/my-service/target"
ExecStart=/usr/bin/env java -jar ${PATH_TO_TARGET}/${SERVICE_NAME}.jar server ${PATH_TO_TARGET}/${SERVICE_NAME}.yml

[Install]
WantedBy=multi-user.target

To read the service's log, just use journalctl in the usual way. A service manager tracks processes by remembering their process IDs from when it spawned them, and has no need of the rickety and dangerous PID file mechanism.

Further reading

Improve this answer
1
  • Thank you very much for your answer. I inherited the scripts and SW service. I follow the instructions and could start the services (5 in total) in VBox (Centos 7 min) and they were working fine. - that is strange. On another cloud instance it gives this error. I am new to services, but started reading systemd docs. My apology for not answering before, I am literary forced to do some other tasks and soon I will be back - and write the feedback. Thanks again.
    – ganna07
    Apr 4, 2018 at 21:51
3

You misplaced an equals character in my-portal.service. Also, you should get rid of the shell script and get SystemD to manage the process directly.

Try this:

[Unit]
Description=My Portal Service
After=network.target

[Service]
Type=Simple
ExecStart=/usr/bin/java -jar /opt/apps/egp/stage/my-portal/target/my-portal.jar server /opt/apps/egp/stage/my-portal/target/my-portal.yml

[Install]
WantedBy=multi-user.target
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .