Centos – Unknown lvalue ‘After network.target’ in section ‘Unit’ Centos 7

centosservices

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?

Best Answer

.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

Related Question