Re: Persisting vblade exports

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ed Cashin wrote...

> In the past it has been difficult to say anything specific about startup
> that applies to a majority of popular Linux distributions.
>
> I think we're still in that situation, but perhaps systemd could change it.
> I know there are a few distros that do not use systemd, though.
>
> I don't think you could go wrong in trying to create something helpful.

It's been a while, but eventually I created a few things:

Please pull from <https://github.com/cbiedl/vblade>,
or download from <https://www.in-ulm.de/~cbiedl/vblade-persistence.tar.xz>


In the `contrib/persistence/` subdirectory you'll find several files:

* vblade-persistence.txt

  Documentation in the asciidoc format (I'm too lazy to write *roff).

* vblade.service
* vblade@.service
* vblade-generator

  Service files and generator for systemd.

* vblade.init.lsb-daemon
* vblade.init.daemon

  Two different flavours of a SysV init script, see
  vblade-persistence(5).

  Both are based on daemon(1). I've prepared something that uses
  Debian's start-stop-daemon(8) - but this requires pid file support
  in vblade and I'm not convinced adding this is worth the efforts.

* vblade.init.in
* vblade.init.generate

  Template and generator for these init scripts.


That's some stuff to read, so just the key points:

Configuration is in `/etc/vblade.conf.d/`, each export (or "instance")
is a file there, name ending in `.conf`.

Using lowercase variable names in the configuration is my personal
preference, YMMV.

By intention I did not implement a mechanism to override settings from
a global configuration file. There are some pitfalls in the handling of
vblade options and I doubt it's worth to deal with them.


The init scripts have been tested to some extent. The systemd variant
has been in production for a few days now and seems to be stable.
Still, the systemd generator could use a review, I haven't understood
all the gory details yet. Controlling the I/O scheduling is an
important feature for me but gave me quite a a headache.

So before anyone asks,

    EnvironmentFile=/etc/vblade.conf.d/%I.conf
    ExecStart=/usr/sbin/vblade $shelf $slot $netif $filename $options
    IOSchedulingClass=$ioschedulingclass
    IOSchedulingPriority=$ioschedulingpriority

does *not* what it suggests. Seems definitions from EnvironmentFile
do not apply for the IO* directives.

Cheers,
    Christoph
-- 

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Aoetools-discuss mailing list
Aoetools-discuss@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/aoetools-discuss



[Index of Archives]     [Linux ARM Kernel]     [Linux SCSI]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux