cancel
Showing results for 
Search instead for 
Did you mean: 

dbsvc generates incorrect service names on Centos 7 build 1511 x86_64

Former Member
2,074

When I attempt to create a native systemd service in SQL Anywhere 17.0.4.2098 on Centos 7 x86_64 build 1511:

dbsvc -t Network -as -w licensing -xs http\\(port=8082\\) /var/local/sadb/licensing/license.db

or a Sys V init service:

dbsvc -i lsb -t Network -as -w licensing -xs http\\(port=8082\\) /var/local/sadb/licensing/license.db

the file created for the service is misnamed. For example, with the lsb option, it should have been /etc/init.d/SA_licensing, but it ended up being just /etc/init.d/SA_ ... what am I doing wrong?

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

You are not doing anything wrong.

The dbsvc (and on Windows SQL Central) creates services with a prefix to differentiate that from possibly other services. On Windows the prefix is based upon the service type (-t) being used. On Linux/Unix it appear this prefix is just 'SA_' this is what you are seeing in action here.

DBSVC -U and -X also work with these prefixes so there should be no confusion when using our utilities.

Former Member

Yes, but the problem is that the service name in 17 ends up just being the prefix SA_ ... the actual service name specified by the -w switch is being dropped.

If I run the dbsvc utility from 12.0.1 and specify -w foo in my service creation options, the service names created are sqlanys_foo and SA_foo on Windows and Linux respectively.

However, the dbsvc utility from 17.0.0 - 17.0.4 creates services named sqlanys_foo on Windows and SA_ (without the specified service name) on Linux respectively, the end result being that you can't create two different database services easily on Linux with different names, because the systemd/init scripts have duplicate names. This appears to be a bug.

Former Member
0 Kudos

Okay ... that is much clearer ... checking into it

Former Member
0 Kudos

We have a 2nd thread indicating the same issue occurs on Debian 8 but not on Debian 7.x.

This problem may have more to do with the shell or new features to your CentOS 7.

Can you force this be used in Bash (if different from the shell you are using) and see what that produces on your side?

Former Member
0 Kudos

Do check out that other thread. It appears Terry may have a solution for this.