0

I have a udpater.service script meant to start a service application. The problem is that when I run the update job as a regular user, it works just fine. The minute that I try to do the same as a service... it fails to work. This is the updater.service in question:

# this is the updater service script.

[Unit]
Description=Meant to update the backup DB.

[Service]
SyslogIdentifier=Update_Backup_DB
Type=forking
User=update_user
WorkingDirectory=/common/deploy/scripts
ExecStart=/common/deploy/scripts/update_db.sh start
ExecStop=/common/deploy/scripts/update_db.sh stop
ExecReload=/common/deploy/scripts/update_db.sh restart

update_user is the user under which everything is supposed to run. The only thing that I can guess that's different are the environment variables. If I log into the server as update_user and print out "env", I see dozens of environment variables. If I print out "env" as the first executable line in update_db.sh, I see about 7 environment variables. It seems that not everything is being included in the runtime environment when update_db.sh is being run as a service. Is there a way to import the same environment variables when update_db.sh is run as a service?

gp443
  • 231
  • 2
  • 11
  • 1
    Don't. It's a bad idea. Users' dotfiles are configured for interactive use and subject to preferential change at any time. (I did write an answer telling someone how to do it, and have linked the duplicate question where that answer was given... but still, you don't want someone deciding they want to change how their interactive shell works to break your services). – Charles Duffy Jan 07 '22 at 15:46
  • 1
    BTW, using `update_db.sh stop` and `update_db.sh restart` implies that `update_db.sh` is responsible for finding other copies of itself and otherwise duplicating functionality that systemd itself has built-in. It's generally a much better approach to change `Type=forking` to `Type=simple` and use an invocation method that doesn't try to self-daemonize -- you get `stop` and `restart` for free, and there's no potential for conflict from different tools trying to track process status in different ways. – Charles Duffy Jan 07 '22 at 15:50
  • Hi Charles, thanks for the link, I didn't find it when I looked. I suppose I could experiment with having a separate file with all of the environment vars in them. Also, the service would read (not write) from /home/update_user/.bashrc, so I think that this would be safe. And changes to that file should be very very infrequent, if ever. – gp443 Jan 07 '22 at 16:28
  • _nod_, it's better if it's a service account, to be sure; a lot of my cautions are most relevant for users who run a service as the account they also use interactively. That said, if the service runs as `update_user` (and thus can write to that user's home directory), that makes it easy for an attacker who finds a RCE vulnerability in the service to persist themselves. Better for services to have read-only home directories or none at all (`/var/empty` or the like). – Charles Duffy Jan 07 '22 at 16:56

0 Answers0