Centos7 systemctl start unit not found

Question

I look everywhere and just for the life of me figure out why systemctl would not start my unit.

I am trying to start GCP's cloud-sql-proxy as a systemd service. This is what my cloud-sql-proxy.service looks like.

[Install]
WantedBy=multi-user.target

[Unit]
Description=Cloud SQL Proxy
Requires=networking.service
After=networking.service

[Service]
Type=simple
WorkingDirectory=/opt
ExecStart=/opt/cloud_sql_proxy -instances=pupa=tcp:5432 -credential_file=/etc/pupa-240309-5336639b0c06.json
Restart=always
StandardOutput=journal
User=root

I ran sudo systemctl enable cloud-sql-proxy successfully. Then when I execute sudo systemctl start cloud-sql-proxy.service it failed with this message:

Failed to start cloud-sql-proxy.service: Unit not found.

Here are more information:

$ ll -al /etc/systemd/system/cloud-sql-proxy.service
-rw-r--r--. 1 root root 327 May 22 10:56 /etc/systemd/system/cloud-sql-proxy.service

$ sudo systemctl list-unit-files
...
cloud-sql-proxy.service                       enabled
...

$ systemctl status cloud-sql-proxy
● cloud-sql-proxy.service - Cloud SQL Proxy
   Loaded: loaded (/etc/systemd/system/cloud-sql-proxy.service; enabled; vendor preset: disabled)
   Active: failed (Result: resources) since Sun 2019-05-19 15:49:48 UTC; 3 days ago
 Main PID: 1414 (code=exited, status=1/FAILURE)

May 19 15:49:48 instance-1 systemd[1]: cloud-sql-proxy.service: main process exited, code=exited, status=1/FAILURE
May 19 15:49:48 instance-1 systemd[1]: Unit cloud-sql-proxy.service entered failed state.
May 19 15:49:48 instance-1 systemd[1]: cloud-sql-proxy.service failed.
May 19 15:49:48 instance-1 systemd[1]: cloud-sql-proxy.service holdoff time over, scheduling restart.
May 19 15:49:48 instance-1 systemd[1]: cloud-sql-proxy.service failed to schedule restart job: Unit not found.
May 19 15:49:48 instance-1 systemd[1]: Unit cloud-sql-proxy.service entered failed state.
May 19 15:49:48 instance-1 systemd[1]: cloud-sql-proxy.service failed.

Any suggestion on where I missed? Thank you!

Solution 1

Can you try something like this in /usr/lib/systemd/system/cloud_sql_proxy.service

[Unit]
Description=GCP CloudSQL Proxy
After=network.target

[Service]
User=root
Group=root
WorkingDirectory=/usr/bin
Type=forking
RemainAfterExit=yes
ExecStart=/bin/sh -c '/usr/bin/nohup /usr/local/cloud_sql_proxy -instances=${INSTANCE_CONNECTION_NAME} -credential_file=${CREDENTIAL_FILE} &'
StandardOutput=journal
KillMode=process

[Install]
WantedBy=multi-user.target

Your config file will be /usr/lib/systemd/system/cloud_sql_proxy.service.d/settings.conf

[Service]
Environment=INSTANCE_CONNECTION_NAME=[YOUR CONNECTION NAME]
Environment=CREDENTIAL_FILE=[PATH TO YOUR CREDENTIAL FILE]

Solution 2

In my experience, this has been due to one of the services in Requires not being found. If you're able to enable your service but starting your service returns Unit not found then examine the services under Requires. In my case, I had a Requires: rpcbind.service but that service was not installed on my system.

Solution 3

I think you're following this [1] link, but if you look at the bottom, they specify that you need to use a different file if you want to do the same on Centos 7. Maybe that is why it is failing.

For Centos 7, use the following:

[Install]
WantedBy=multi-user.target

[Unit]
Description=Google Cloud Compute Engine SQL Proxy
Requires=network.target
After=network.target

[Service]
Type=simple
WorkingDirectory=/usr/local/bin
ExecStart=/usr/local/bin/cloud_sql_proxy -dir=/var/run/cloud-sql-proxy -instances=<instance_connection_name>=tcp:3306 -credential_file=/var/local/cloud-sql-proxy/<credential_json>.json
Restart=always
StandardOutput=journal

[1] https://gist.github.com/goodwill/a981c2912ae6a83761a624f657f34d9f

Comments

[Sergey Nudnov]

Could you please provide directly in your answer the settings which should, as you think, help

[Mickey]

Removing Requires=networking.service did the trick! Thanks

[aaaaaa]

wow not a fun error message. In my case the required unit existed but was system level. The unit I was trying to start was user level. Per another SO answer "User units can not reference or depend on system units." unix.stackexchange.com/a/278572/24314