[SOLVED] bash: sleep not a builtin?

ondoho · 2014-01-03 09:30:17

hello,
i have a few scripts running in endless loops, using the sleep command.
this causes constant i/o - not much, but nevertheless.
i went to investigate this further and found that on (archlinux') bash, sleep is not a builtin by default, nor can it be enabled with the "enable" command.
this seems less than optimal to me.
i can't find any packages that would remedy that, either.

how can i solve this?

thoughts, most preferable first:

1) there is some other bash-builtin i've missed, or some workaround that has the same effect.
2) copy the sleep command to /dev/shm/bin and add that to my path. feels hackish, but why not?
3) recompile bash (i read the debian version has sleep as a builtin)?
4) change to another (preferably bash-compatible) shell?

cheers,

o.

Last edited by ondoho (2014-01-06 21:29:31)

progandy · 2014-01-03 11:28:58

You can download the bash source and make example/loadables yourself, then use enable to load it.

teateawhy · 2014-01-03 12:59:35

ondoho wrote:

i have a few scripts running in endless loops, using the sleep command.

5) Use cron or a daemon?
https://wiki.archlinux.org/index.php/Cron
https://wiki.archlinux.org/index.php/Daemon

ondoho · 2014-01-03 22:55:40

@progandy: thanks, that seems sensible, but also a lot of work. but since there doesn't seem to be any other way, i'll try that i guess. can you give further pointers/links/howtos?

edit: this looks interesting and easier than i thought.

Last edited by ondoho (2014-01-03 22:57:59)

2ManyDogs · 2014-01-03 23:00:55

ondoho wrote:

hello,
i have a few scripts running in endless loops, using the sleep command.

man at

?

ondoho · 2014-01-03 23:18:45

2ManyDogs wrote:

man at

?

definitely interesting, but it doesn't allow for seconds. minutes, days, hours, but not seconds.
but thanks anyway.

i'm halfway through compiling bash with the loadables included, looks promising...
i wonder if archlinux really left them out for lightweightness, or maybe i'm searching in the wrong place...

progandy · 2014-01-03 23:20:07

ondoho wrote:

@progandy: thanks, that seems sensible, but also a lot of work. but since there doesn't seem to be any other way, i'll try that i guess. can you give further pointers/links/howtos?
edit: this looks interesting and easier than i thought.

This should work:

bsdtar -xf bash-4.2.tar.gz
cd bash-4.2
./configure
make pathnames.h
cd builtins
make builtext.h
cd ../examples/loadables
# make
# or just a specific loadable:
make sleep
enable -f ./sleep sleep

Last edited by progandy (2014-01-03 23:23:05)

2ManyDogs · 2014-01-03 23:22:57

Maybe ask yourself why this is difficult, and why you might be the first person to notice this? Perhaps there is a better way than multiple processes just waiting? Anyway, good luck.

Last edited by 2ManyDogs (2014-01-03 23:29:42)

livibetter · 2014-01-04 08:58:40

ondoho isn't the first one noticed issue with sleep, I believe I wouldn't be first, either. Nevertheless, I think he might be concerning too much if the sleep time is at least 1 second.

When I noticed I have issue with sleep about a year ago, from another point, I saw the execution time, not the I/O, which I've not thought about before. Here is data I collected with Bash 4.2*:

CMD                  I=1000           I=2000           I=3000
/bin/sleep 0.001     3.002s (200.2%)  6.014s (200.7%)  9.026s (200.9%)
read -t 0.001 -N 0   1.113s ( 11.3%)  2.226s ( 11.3%)  3.339s ( 11.3%)
builtin sleep 0.001  1.129s ( 12.9%)  2.254s ( 12.7%)  3.379s ( 12.6%)

The problem is with executing external command, but if the sleep time is not small, then it should be okay to ignore.

Interestingly, by using `read` it somehow gets a little better result. The drawback is OS X seems to have older Bash and whose `read` doesn't support fraction. Also the builtin `sleep` doesn't support suffixes, i.e. "h", "m", "s" You might want to be careful about portability.

Believe or not, I even have a virtually loadable extension PS1, my Bash prompt is written in C. I was a little obsessive with speed and efficient at the time.

* I'm not a Arch user, I use Gentoo.

brewlius_cesar · 2014-01-04 11:32:51

If you have such an obsession with performance (< 6s difference after 3000 iterations), then you should probably just write a small C program which performs your task as opposed to trying to do it in a shell script...

ANOKNUSA · 2014-01-04 15:06:25

Isn't the purpose of "sleep" in a shell script to momentarily pause a single process with a definite end and/or prevent race conditions? Frequent reiteration of tasks at regular intervals is what cron jobs were made for. I'll admit some ignorance in such things, but unless you're running a script that depends entirely on variying, returned values from the each iteration, I don't see the point of constantly wracking your disk and CPU.

ondoho · 2014-01-05 09:55:12

@progandy: thanks a bunch for the step-by-step - i had errors about not finding header files before, but now it works and has the desired effect - no more disk i/o from sleep anymore.

@livibetter: thanks for "read -t" - i didn't know about that option. i guess it's a solution equally good as what i have now.

@all:
i stated clearly in my first post that my concern is disk i/o, not performance.
i also clearly stated that i am looking for different kinds of solutions.
but i didn't describe the scripts in question properly, so here goes:
it's mostly 1 shellscript piping various system data into dzen, by means of a number of functions, all of them query some value every few seconds. or diplaying the time, currently playing song and so on.
some of the functions can be paused with inotifywait, some can't. or i don't see how.
i would still be happy to hear other suggestions!

i can't avoid the script using the hard drive altogether, but this really is a more general question. it applies to all sorts of scripts.

ps: i'll wait a couple days before marking this as solved, because some people hinted at other/better solutions.

Last edited by ondoho (2014-01-05 09:55:50)

livibetter · 2014-01-05 11:10:32

dzen for system resource monitoring was something I wanted to bring up, but I wasn't sure what purpose of your script, so I didn't bring it up.

About two or three years ago, I switched to dzen from Conky for system resource monitoring. Like many people, suggestions, and examples on the Internet, I used Bash to write the script [1] to feed the data into dzen. It wasn't long before I realize the script had eaten up 100MB memory.

It was the time I first noticed the issue with Bash scripting. Yes, there are times for cron and should be used with cron, but for this situation and type of case, you can't. I did try to isolate the problem by removing some monitoring components, but, IIRC, the memory was still being eaten.

The 3,000 iterations in my previous might sound a lot at first glance, but the point isn't the iterations but how many invocations of external commands. And 3000 calls of external externally actually ain't a lot, even for one-off or once in long time scripts. That's where the problem is linked from what I see, although I still don't know what the actually cause is.

After I failed to find the leak--or is there really one? I ported the Bash script to C [2]. It's much efficient.

Note that for both code, they are updating as fast as 0.2 seconds depending on what system resources. I found 1 second is too long, especially when you are pressing volume up key, even it's roughly okay for system clock.

I'd advise everyone to take a close look at "TIME+" in top/htop, you might find some programs that you don't expect to use that much time and some the other way around.

By the way, when I said "little obsessive" about myself, I only meant PS1 in loadable C extension is obsessive--who even does like `enable -f vimps1 vimps1` for your PS1? But other parts don't count, because those are clearly wasting if the code is executed a lot and you don't deal with.

[1]: https://github.com/livibetter/dotfiles/ … /status.sh
[2]: https://github.com/livibetter/dotfiles/ … n/status.c

teateawhy · 2014-01-05 17:44:51

Note that for both code, they are updating as fast as 0.2 seconds depending on what system resources. I found 1 second is too long, especially when you are pressing volume up key...

For showing the volume level, i use volnoti, which shows a volume notification only when the volume up/down key is pressed. I still have the volume level displayed in the statusbar, but the statusbar is only updated every 5 seconds.
EDIT: My statusbar contents are created with: i3status, that is written in C like livibetter suggested.

Last edited by teateawhy (2014-01-05 17:47:53)

ondoho · 2018-11-16 06:01:43

nowadays the archlinux bash package contains a loadable sleep module (not sure that's the right term) which can be enabled with sth like this:

for file in /usr/lib/bash/sleep /usr/lib32/bash/sleep /usr/lib64/bash/sleep; do
    [ -r "$file" ] && enable -f "$file" sleep && break
done
# Portable enough?

topic can be closed now.

ewaller · 2018-11-16 15:15:26

ondoho wrote:

topic can be closed now.

Done

Arch Linux

#1 2014-01-03 09:30:17

[SOLVED] bash: sleep not a builtin?

#2 2014-01-03 11:28:58

Re: [SOLVED] bash: sleep not a builtin?

#3 2014-01-03 12:59:35

Re: [SOLVED] bash: sleep not a builtin?

#4 2014-01-03 22:55:40

Re: [SOLVED] bash: sleep not a builtin?

#5 2014-01-03 23:00:55

Re: [SOLVED] bash: sleep not a builtin?

#6 2014-01-03 23:18:45

Re: [SOLVED] bash: sleep not a builtin?

#7 2014-01-03 23:20:07

Re: [SOLVED] bash: sleep not a builtin?

#8 2014-01-03 23:22:57

Re: [SOLVED] bash: sleep not a builtin?

#9 2014-01-04 08:58:40

Re: [SOLVED] bash: sleep not a builtin?

#10 2014-01-04 11:32:51

Re: [SOLVED] bash: sleep not a builtin?

#11 2014-01-04 15:06:25

Re: [SOLVED] bash: sleep not a builtin?

#12 2014-01-05 09:55:12

Re: [SOLVED] bash: sleep not a builtin?

#13 2014-01-05 11:10:32

Re: [SOLVED] bash: sleep not a builtin?

#14 2014-01-05 17:44:51

Re: [SOLVED] bash: sleep not a builtin?

#15 2018-11-16 06:01:43

Re: [SOLVED] bash: sleep not a builtin?

#16 2018-11-16 15:15:26

Re: [SOLVED] bash: sleep not a builtin?

Board footer