Re: Source bash scripts in execline
Shell functions can only be sourced into a shell interpreter; execline is not a shell interpreter. You can, of course, have execline exec a shell, passing it a script that tells it to source your file before running whatever code requires the functions provided. On Tue, Dec 15, 2020 at 2:42 AM billa chaitanya wrote: > Hi Team, > In execline, How to do sourcing of bash script which contains small > functions. > envfile can be used to source variables. Since the script has some > functions, I'm not sure how to handle this. > "Source" is not working. Is there any other way i can source the bash > script which contains functions in execline ? > > Thanks! >
Re: Uncontrolled generation of new processes
As an aside, set -e is by no means unambiguously considered good practice.
See the list of exercises (below the allegory) in BashFAQ #105 at
http://mywiki.wooledge.org/BashFAQ/105 to see if you understand its
(extremely unintuitive) behavior in corner cases, and an extended listing
of the many incompatibilities between different shells' implementations of
set -e at https://www.in-ulm.de/~mascheck/various/set-e/.
Generally, a well-behaved service script should just exec your service
(configured in such a way as to not self-daemonize) -- that way the service
itself owns the PID that previously belonged to the shell, and the
supervision system can determine whether the service exited by looking at
that PID itself.
On Sun, Dec 10, 2017 at 12:05 PM DGSJ wrote:
> On Thu, Dec 07, 2017 at 06:09:08AM +, Colin Booth wrote:
> > On Wed, Dec 06, 2017 at 05:35:46PM +0100, DGSJ wrote:
> > > Hallo.
> > > In order to migrate my SistemV to Runit, I'm writing the service
> scripts,
> > > but I'm having a problem I can't solve.
> > All right, lets take a look!
> > >
> > > First, lest see an example that works well. The run file for the
> > > touchpad mouse:
> > >
> > > #!/bin/bash
> > > [ -f /etc/sysconfig/mouse ] && . /etc/sysconfig/mouse
> > > echo -e "Mouse working (ratonpad)..."
> > > exec /usr/sbin/gpm -D -m "${MDEVICE}" -t "${PROTOCOL}" ${GPMOPTS} >
> /dev/null 2>&1
> > >
> > > An this is how the processes and PID's look like.
> > > # ps -fx
> > > 1 ?Ss 0:00 runit
> > > 192 ?Ss 0:00 runsvdir -P /service log: ..
> > > .
> > > 194 ?Ss 0:00 \_ runsv ratonpad
> > > 198 ?S 0:00 | \_ /usr/sbin/gpm -D -m /dev/input/mice
> -t imps2
> > >
> > > This kind of run file seems to work fine with daemons like gpm,
> sysklogd
> > > syslogd...
> > >
> > > But when I try to make the same with other services like udev,
> something
> > > goes wrong.
> > >
> > > This is the run file:
> > > #!/bin/bash -e
> > > echo "daemon udevd"
> > > exec 2>&1
> > > exec /sbin/udevd --daemon
> > >
> > > And this is what happens:
> > > 466 ?Ss 0:00 /sbin/udevd --daemon
> > > 470 ?Ss 0:00 /sbin/udevd --daemon
> > > 474 ?Ss 0:00 /sbin/udevd --daemon
> > > 478 ?Ss 0:00 /sbin/udevd --daemon
> > > 484 ?Ss 0:00 /sbin/udevd --daemon
> > > 488 ?Ss 0:00 /sbin/udevd --daemon
> > > 492 ?Ss 0:00 /sbin/udevd --daemon
> > > 496 ?Ss 0:00 /sbin/udevd --daemon
> > >
> > > The processes doesn't fit into the typical runsv tree, and every one
> second
> > > a new PID is created on and on.
> > >
> > > What can be wrong?
> > systemd-udevd(8) says: --daemon Detach and run in the background.
> >
> > The main thing about supervision is that things shouldn't background
> > themselves, otherwise the supervisor loses track of it and spawns a new
> > copy. Dropping the `--daemon' should fix it.
>
> Yes, fixed as you said.
>
> > >
> > > With other more elaborated run files, for services different than
> daemons,
> > > it happens more or less the same. Let see the behaviour of this
> > > interesting template I have found.
> > >
> > > This is the run file.
> > > #!/bin/bash -e
> > > echo -e "-"
> > > exec 2>&1
> > > exec /opt/example2/foo-service.sh
> > >
> > > This is the script for the foo-service.sh
> > > #!/bin/bash -e
> > > echo "Empieza el servicio...root (service begins)"
> > > for i in {1..2}
> > > do
> > > echo "haciendo cosas...root (making things...)"
> > > sleep 1
> > > done
> > >
> > > It doesn't matter if you end the script with exit 1 o 0, the result,
> > > regarding the uncontrolled creation of PID's is the same.
> > >
> > > This is the output of ps -fx
> > >
> > > 197 ?Ss 0:00 \_ runsv example2
> > > 820 ?S 0:00 \_ /bin/bash -e
> /opt/example2/foo-service.sh
> > > 821 ?S 0:00 \_ sleep 1
> > >
> > > It looks nice, but after a while:
> > > 197 ?Ss 0:00 \_ runsv example2
> > > 989 ?S 0:00 \_ /bin/bash -e
> /opt/example2/foo-service.sh
> > > 991 ?S 0:00 \_ sleep 1
> > This is a matter of confusion on the part of the user. ./run is being
> > replaced via exec with foo-service.sh, a program that does three things:
> > echoes some stuff, forks a one-second sleep, and then exits. Once it
> > exits, the supervisor (runsv) will re-launch it.
> > >
> > > Old processes are killed, and new ones created every second
> > > 820 - 821 --> 989 - 991.
> > >
> > > Another view with pstree.
> > > |-runsvdir-+-runsv---login---bash---
> > > | |
> > > | |-runsv---gpm
> > > | |-runsv---syslogd
> > > | |-runsv-+-klogd
> > > | | `-run---svlogd
> > > | `-runsv---foo-service.sh---sleep
> > >
> > >
> > > Well, I think I've missed something
Re: execlineb's import conflicts with ImageMagick
Given as GraphicsMagick moves "import" to a subcommand ("gm import"), you
might consider using it to avoid any conflict.
On Sun, Oct 22, 2017 at 4:12 PM Jean Louis wrote:
> The ImageMagick software has the "import" command
> that is conflicting with "import" from execlineb
> package.
>
> Jean
>
Re: s6 as a systemd alternative
Could you be more clear about what you mean by "make systemd compatible"? Do you mean loading systemd configuration files into s6, or the reverse? The former strikes me as exceedingly difficult to implement in a complete and correct manner. One of the things that makes systemd so... controversial... is the amount of complexity it pulls into what (in many folks' view) ought to be designed as a simple subsystem (in the "simple enough that an implementation can be obviously correct" sense). Because of that amount of complexity -- one could rather easily implement a simple subset of its functionality, but reaching full parity (and *maintaining* that parity as it continues to grow, expand, and cross what would historically be distinct subsystem boundaries) strikes me as a very ambitious project. As a few examples of things that systemd provides that would need to be reimplemented: - A mechanism based on UNIX domain sockets for implementing a watchdog, and for processing file descriptors between subsequent invocations of the same service. - Sandboxing of allowed syscalls (using a Linux-only mechanism not applicable to other platforms s6 supports) - Management of process-local filesystem, PID, and user namespaces (again, using a Linux-only mechanism) - Integration with a (again, linux-only and glibc-only) nsswitch module to generate dynamic, transient user accounts local to an individual instance of a process - Integration with the linux-only cgroups mechanism for managing CPU, memory, and I/O throughput limits ...and so on, and so forth. Consequently, any effort would necessarily be a small subset, and plagued by compatibility issues whenever a distributed .service file attempts to use functionality that a different process supervision system couldn't implement without compromising portability (or changing its behavior between platforms). On Mon, Jun 26, 2017 at 9:02 AM Istvan Szukacs wrote: > Hi, > > I have a crazy question about s6. Would it be possible to make systemd > compatible? This question might sound stupid at first but here is the > reasoning: > > - we have services with systemd service files already > (/etc/systemd/system/*.service, etc.) > - the previous alternatives all failed to gain traction because there was > too much effort to change systems around to use them ( > https://www.tecmint.com/best-linux-init-systems/) and the linux platform > is > very fragmented > - there is already too much effort went into systemd that would be hard to > duplicate > > Questions: > > - is there anybody interested in such project? > - is this feasible to do? > > Let me know what you think. > > Thanks in advance, > Istvan > > -- > *Istvan Szukacs* > CTO > > ist...@streambrightdata.com >
Re: Re[2]: Runit questions
Correct, cgroups can be used from any process supervision system. As for socket activation, this too can be implemented on top of a traditional supervision system, with no need for it to be baked into the core. See http://smarden.org/ipsvd/ for an example implementation. Granted, this one doesn't have pre-spawning support as systemd's socket activation does, but there's no reason someone couldn't write a similar shim that did -- frankly, there's just not a lot of call for the feature. I do a great deal of work with systemd shop in my day job -- and while it works reasonably well in the basic cases, I've also hit far more than my share of bugs and bizarre corner cases. One of the beautiful things about systemd is its simplicity: It promises a very small number of behaviors, implements them well, and lets anything additional be implemented out-of-band. On Tue, Oct 11, 2016 at 9:36 AM Andy Mender wrote: > Dear Jan, Laurent, > > Thank you kindly for answering my questions and clarifications :). I'm > slowly starting to have a general idea of how to use runit, > but I will definitely have streams of questions in the nearest future. As > far as I understood, the point is to avoid extensive scripting hodgepodge > within run scripts to avoid replicating System V init limitations, correct? > > Since dependency resolution is not done by runit, any inter-daemon > communication is down to the capabilities of individual daemons, right? > Case in point, if a specific daemon "talks" to another daemon via dbus, > none of the runit programs care about this, because the daemon > should know how to "do the talking" itself, right? > > > Finally, in the systemd-sphere there is some emphasis on cgroups and socket > activation. How relevant are those features in your opinion? > Within the articles I read it was pointed out that cgroups are a kernel > feature and there is a sizeable section of the kernel .config devoted to > that. > Thereby, in theory any init can take advantage of that. Is that correct? > What about socket activation? > > Best regards, > Andy > > On 11 October 2016 at 13:33, Laurent Bercot > wrote: > > > > > >> 2. If several services rely on a common daemon, like dbus or > > udev/eudev, is > > >> the said daemon launched multiple times? > > > > No. One service directory = one daemon instance. If you have a service > > directory for dbus-daemon, it will be launched once, no matter how many > > times you "sv up" that service directory. > > > > > > Runit doesn't track dependencies directly, but it can handle them. This > is > >> done by calling sv start $DEP_1 $DEP_2 etc. in the ./run script. > >> > > > > I would advise against starting dependencies in a run script. > > Idiomatically, > > a run script should only impact the service it's representing, and > nothing > > else; baking in dependencies into run scripts is a slippery slope leading > > to more problems. > > > > The two common approaches to dependencies in supervision suites are: > > > > - Do nothing. If all dependencies of a service are up, the service will > > start normally. If they aren't, the service will fail to start, and the > > supervisor will automatically make another attempt shortly after. > > Eventually everything will be up. > > This approach is reasonable when all dependencies are longrun services > > (processes that can be supervised) and restarting the processes isn't > > too costly. > > > > - Having a real service manager - like s6-rc, anopa, or OpenRC - handle > > dependency management. This works in every case, but is the heavier > > approach. > > > > > > 3. I noticed the ./run scripts are essentially Shell scripts by default. > >>> Does this resolve the commonly perceived > >>> limitations of System V init scripts? > >>> > >> > > The limitations of System V scripts does not come from the fact that > > they're > > shell scripts. They come from the fact that they don't have a supervision > > framework to start their daemons in, and thus have to resort to ugly > hacks > > to perform what is essentially free with a supervision suite: > > backgrounding, > > logging, storing the pid to find the daemon later, etc. Also, they have > > to work both in the boot scripts' environment and a root shell's > > environment, > > and must not inherit anything from that root shell, which leads to a lot > of > > dirty boilerplate. > > > > All those concerns disappear in a run script, because you don't need a > pid > > file, you don't need to background, you don't need to do anything except > > put your current process into the desired state and execute into your > > long-running program. The environment a run script is launched in is > > always the same and there's a lot of infrastructure already in place, so > > most of the boilerplate disappears. As Jan says, what remains is very > > simple and very repetitive - it's just about setting the right process > > state. > > > > -- > > Laurent > > > > >
Re: How to supervise an early process [root pivot]
Couldn't one play with bind mounts to keep the absolute paths consistent on both sides of the pivot operation? On Tue, Jun 21, 2016 at 10:02 AM Laurent Bercot wrote: > On 21/06/2016 16:24, Martin "eto" Misuth wrote: > > Reinterpreting based on my personal experience, situation would be > basically > > similar to - "deleting" servicedirs from "underneath" running s6-svscan > one (I > > did that one to myself due to script error, don't ask): > > No, it's not the same thing. When you pivot_root, everything is kept > open, > the inodes do not change, everything keeps working - except that the > absolute paths to the files are not the same anymore. If you were referring > to a service as /service/foo beforehand, it has to be referred to as > /old_root_location/service/foo after a pivot_root. > > If you used absolute paths to link servicedirs into your scandir, and you > pivot_root, then s6-svscan will rightfully freak out on its next scan. But > s6-supervise should keep working - the control interface hasn't > disappeared, > it is just named differently. > > > > Would it be possible to somehow "posixly" lock control files in such > way, that > > remount/pivot_root/unlink would fail and one could not delete them > without force > > flag, indicating indeed sysadmin error? > > No. Well, there are "extended attributes" that allow you to do that kind > of > thing, but I'm not sure to what extent those are portable. But they > wouldn't > protect you against pivot_root anyway, because no files are deleted or > changed when you pivot_root, it's just a rotation in the directory tree. > (Also, trying to protect admins against themselves is doomed to fail, and > a sure recipe for bad design.) > > The only sensible "protection" against pivot_root is: do your pivot_root > very early when basically nothing is running, and start your supervision > tree later on. > > -- > Laurent > >
Re: How to supervise an early process
Hmm. I'd actually tend to suggest using a lockfile (and then looking for programs with a handle on that file to kill with fuser or a like tool) rather than the error-prone practice of grepping ps, and the similarly-error-prone practice of using killall. Granted, if starting in the initramfs, that means a bit of care (ie. to already mount whichever filesystem one will be creating the lockfile on before pivot, or to create a tmpfs filesystem or such which can be moved into the new tree), but I'd argue it to be worthwhile. On Sun, Jun 19, 2016 at 10:57 AM Steve Litt wrote: > Hi all, > > A big objection to most supervision type init systems is that for a > given process you must choose between early, like run from the rc > script(s) preceding running of the supervisor, and respawning > supervision. > > I just thought of a theoretical hack to have both. > > Symlink to give the executable a new name. > > ln -s myapp myapp_sym > > Run myapp_sym as early as you want in the rc file. Heck, run it in > the initramfs for all I care, and let it switch_root over. Then, in the > run script for any supervision suite, do this: > > === > #!/bin/sh > if ps ax | grep myapp_sym; then > killall myapp_sym > fi > > exec myapp > === > > Obviously, for some apps, you'll need to shut down a little more > gracefully than killall, but whatever way you need to shut down, you > just put it in the if statement or in a shellscript called from > within the if statement. > > This should work on daemontools, daemontools-encore, runit and s6. It > might run on more, but those four are the only ones I've used. > > One of the outstanding benefits of supervision suites is how malleable > they are with a little imagination. > > Thanks, > > SteveT > > Steve Litt > June 2016 featured book: Troubleshooting: Why Bother? > http://www.troubleshooters.com/twb >
Re: Entering a passphrase interactively in a runit script
...if the goal is to avoid storing a private key in plaintext, can that private key live in a hardware store (PKCS#11, TPM, etc) instead? On Thu, May 26, 2016 at 8:49 AM Steve Litt wrote: > On Thu, 26 May 2016 14:16:16 +0100 > Jonathan de Boyne Pollard > wrote: > > > Christophe-Marie Duquesne: > > > Any idea how to proceed? > > > > You're running a daemon. It really shouldn't have an interactive > > user interface. Remember the lessons that resulted in Session 0 > > Isolation in Windows NT. > > The more I read of this thread, the more I think it's a bad idea to > have a boot-instantiated daemon acquire a password by any means, and > the more I think maybe a completely different approach might be more > appropriate. So let me ask the original poster a few questions: > > * What does this daemon do? > * How many users does the machine have? > - At one time? > - Ever? > * Would all the machine's users be expected to know the password? > * Did you write the daemon yourself? > * Why does it need to be a supervised daemon, rather than just a > program the user runs? > > Thanks, > > SteveT > > Steve Litt > May 2016 featured book: Rapid Learning for the 21st Century > http://www.troubleshooters.com/rl21 >
