+1 for using callbacks, we use the Mount and preUnMount callbacks on various things, e.g. before unmount, shutdown all the VMs running on the host, i.e. start and stop other things cleanly when the FS arrives/before it goes away.
Simon From: <[email protected]> on behalf of "[email protected]" <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Thursday, 14 March 2019 at 21:04 To: "[email protected]" <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Re: [gpfsug-discuss] Systemd configuration to wait for mount of SS filesystem But if all you are waiting for is the mount to occur the invocation of the callback informs you the file system has been mounted. You would be free to start a command in the background, with appropriate protection, and exit the callback script. Also, making the callback script run asynchronous means GPFS will not wait for it to complete and that greatly mitigates any potential problems with GPFS commands, if you need to run them from the script. Fred __________________________________________________ Fred Stock | IBM Pittsburgh Lab | 720-430-8821 [email protected] ----- Original message ----- From: "Stephen R Buchanan" <[email protected]> Sent by: [email protected] To: [email protected] Cc: Subject: Re: [gpfsug-discuss] Systemd configuration to wait for mount of SS filesystem Date: Thu, Mar 14, 2019 4:52 PM The man page for mmaddcallback specifically cautions against running "commands that involve GPFS files" because it "may cause unexpected and undesired results, including loss of file system availability." While I can imagine some kind of Rube Goldberg-esque chain of commands that I could run locally that would trigger the GPFS-filesystem-based commands I really want, I don't think mmaddcallback is the droid I'm looking for. Stephen R. Wall Buchanan Sr. IT Specialist IBM Data & AI North America Government Expert Labs +1 (571) 299-4601 [email protected] ----- Original message ----- From: "Frederick Stock" <[email protected]> Sent by: [email protected] To: [email protected] Cc: [email protected] Subject: Re: [gpfsug-discuss] Systemd configuration to wait for mount of SS filesystem Date: Thu, Mar 14, 2019 4:17 PM It is not systemd based but you might want to look at the user callback feature in GPFS (mmaddcallback). There is a file system mount callback you could register. Fred __________________________________________________ Fred Stock | IBM Pittsburgh Lab | 720-430-8821 [email protected] ----- Original message ----- From: "Stephen R Buchanan" <[email protected]> Sent by: [email protected] To: [email protected] Cc: Subject: [gpfsug-discuss] Systemd configuration to wait for mount of SS filesystem Date: Thu, Mar 14, 2019 3:58 PM 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 [email protected] _______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss _______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss _______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
_______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
