[gpfsug-discuss] Systemd configuration to wait for mount of SS filesystem

Trafford, Tyler tyler.trafford at yale.edu
Thu Mar 14 21:38:32 GMT 2019


I forgot to mention that you need to name the unit file something like foo at .service

-Tyler

________________________________________
From: gpfsug-discuss-bounces at spectrumscale.org <gpfsug-discuss-bounces at spectrumscale.org> on behalf of Trafford, Tyler <tyler.trafford at yale.edu>
Sent: Thursday, March 14, 2019 5:36 PM
To: gpfsug main discussion list
Subject: Re: [gpfsug-discuss] Systemd configuration to wait for mount of        SS      filesystem

I use the following:

[Unit]
Description=Foo
After=gpfs.service

[Service]
ExecStartPre=/bin/bash -c 'until [ -d /gpfs/%I/apps/services/foo ]; do sleep 20s; done'
ExecStart=/usr/sbin/runuser -u root /gpfs/%I/apps/services/foo/bin/runme

[Install]
WantedBy=multi-user.target


Then I can drop it on multiple systems (with the same app layout), and run:

systemctl enable foo at fs1
or
systemctl enable foo at fs2

The "%I" gets replaced by what is after that "@".

--
Tyler Trafford
tyler.trafford at yale.edu

________________________________________
From: gpfsug-discuss-bounces at spectrumscale.org <gpfsug-discuss-bounces at spectrumscale.org> on behalf of Stephen R Buchanan <stephen.buchanan at us.ibm.com>
Sent: Thursday, March 14, 2019 3:58 PM
To: gpfsug-discuss at spectrumscale.org
Subject: [gpfsug-discuss] Systemd configuration to wait for mount of SS filesystem

I searched the list archives with no obvious results.

I have an application that runs completely from a Spectrum Scale filesystem that I would like to start automatically on boot, obviously after the SS filesystem mounts, on multiple nodes. There are groups of nodes for dev, test, and production, (separate clusters) and the target filesystems are different between them (and are named differently, so the paths are different), but all nodes have an identical soft link from root (/) that points to the environment-specific path. (see below for details)

My first effort before I did any research was to try to simply use a directive of After=gpfs.service which anyone who has tried it will know that the gpfs.service returns as "started" far in advance (and independently of) when filesystems are actually mounted.

What I want is to be able to deploy a systemd service-unit and path-unit pair of files (that are as close to identical as possible across the environments) that wait for /appbin/builds/ to be available (/[dev|tst|prd]01/ to be mounted) and then starts the application. The problem is that systemd.path units, specifically the 'PathExists=' directive, don't follow symbolic links, so I would need to customize the path unit file for each environment with the full (real) path. There are other differences between the environments that I believe I can handle by specifying an EnvironmentFile directive -- but that would come from the SS filesystem so as to be a single reference point, so it can't help with the path unit.

Any suggestions are welcome and appreciated.

dev:(path names have been slightly generalized, but the structure is identical)
SS filesystem: /dev01
full path: /dev01/app-bin/user-tree/builds/
soft link: /appbin/ -> /dev01/app-bin/user-tree/

test:
SS filesystem: /tst01
full path: /tst01/app-bin/user-tree/builds/
soft link: /appbin/ -> /tst01/app-bin/user-tree/

prod:
SS filesystem: /prd01
full path: /prd01/app-bin/user-tree/builds/
soft link: /appbin/ -> /prd01/app-bin/user-tree/


Stephen R. Wall Buchanan
Sr. IT Specialist
IBM Data & AI North America Government Expert Labs
+1 (571) 299-4601
stephen.buchanan at us.ibm.com

_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
https://nam05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgpfsug.org%2Fmailman%2Flistinfo%2Fgpfsug-discuss&data=02%7C01%7Ctyler.trafford%40yale.edu%7Cb3be6639c012419aaf3908d6a8c518c9%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C0%7C636881961822668372&sdata=4rU%2BWIv1tpJiTOGmliWba2vvTxeJf5gYyJ7xrbdf6wE%3D&reserved=0



More information about the gpfsug-discuss mailing list