Hallo, On 11 September 2014 19:41, Dale R. Worley <wor...@alum.mit.edu> wrote: > > From: Colin Guthrie <gm...@colin.guthr.ie> > > I'm maybe missing something, but in the case of mount units, isn't that > > framework program mount(8)? > > > > It has a mechanism for parsing default options that apply to all mounts > > and then calling out to the appropriate, filesystem specific mount > > program (e.g. mount.nfs, mount.cifs, mount.crypt, mount.fuse etc. etc.) > > if appropriate. > > mount does the real work, of course, but it isn't the complete > solution,
Er, "solution" to what, exactly? People here seem (rightly) unconvinced there's any problem at all. And yes, calling mount -- by definition -- actually is the "complete solution" to mounting a file system under Linux. > because *something* has to figure out not only that > /bin/mount should be invoked, but what its arguments are. > > And as you can see from the unit file > [SNIP] > What=/dev/Freeze02/Store2 > Where=/Store > Type=ext4 [SNIP] > Options=nofail,x-systemd.device-timeout=1m,defaults > > none of that is specified *directly* in the unit file. Now surely, calling /usr/bin/mount $What $Where [-t $Type] [-o $Options] is about as direct as it gets. Being able to substitute the only constant in that equation with /usr/bin/gimp really isn't going to solve any problem, real or imagined. > Some piece of code has to know to assemble the What, Where, Type, > and Options values (at the very least) -- and that piece of code is what > contains special knowledge of how to handle mount units. Again: straightforward use of a standard Unix API that just happens to be in a separate binary != special knowledge. Really. It's programming. Step back, and define exactly what it is you actually need^Wwant to do. >From my reading of the thread, this is to emulate as closely ye olde initscripts' unreliable and flawed behaviour of attempting to mount one or more devices exactly once (i.e., a one-shot "mount -a"), but not until an arbitrary time-out has elapsed after which all external devices are blindly assumed to have been initialised for no good reason. This isn't hard to achieve with systemd, but there's a good reason I wrote it in such a silly manner, that can't simply be ignored. Regards (and good luck nonetheless), T G-R _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel