0

I work in a Linux server which doesn't allow me to use cron. So, to bypass this, I write scripts that needs to run on a definitive time like this:

while true
do
    ...
    ...
    sleep 1d #changes upon requirement of my script
done

I always start the scripts in the background nohup ./script.sh &.

My question is, say I have six/seven scripts like this running on the server - most times they'd be sleeping. Would this - sleep consume some kind of memory? Will it impact the performance of the server? Is there any efficient way to handle this?

mathB
  • 177

2 Answers2

1

sleep is designed to consume almost no resources.

Beware however that sleep can be interrupted for various reasons. You probably want to make sure you don't run your commands (much) earlier than intended.

Satō Katsura
  • 13,368
  • 2
  • 31
  • 50
  • 1
    Could you explain the part about sleep can be interrupted? You mean like a kill or something else? – mathB Nov 01 '17 at 16:49
  • sleep is based on alarm(2). alarm(2) can be interrupted by almost any signal, and it isn't always possible to restart it. – Satō Katsura Nov 01 '17 at 17:06
  • Thanks! Do we have any man page entry for this? How can I learn more about these signals? :) – mathB Nov 01 '17 at 17:21
  • 1
    Read a book about UNIX? man pages are good on OpenBSD, and useful on FreeBSD and NetBSD. Sadly, not that much on Linux. – Satō Katsura Nov 01 '17 at 17:25
1

Yes — you're consuming memory with those scripts. You've actually got two processes running, using memory:

  • a shell (e.g., bash)
  • sleep itself.

sleep is going to be extremely lightweight, but the shell may consume a few megabytes of memory. On my system an idle non-interactive bash consumes ~1MiB and a sleep 0.7MiB. You can check ps or top (look at the RSS column)—though a lot of that total is actually things like libraries which are shared between all processes using them. All in all, it's likely <1MiB each.

On Linux, you can get more details from /proc/pid/status (and /proc/pid/smaps); the Vm* ones are of interest here. For example:

bash -c 'grep Vm /proc/$$/status'
VmPeak:    13380 kB
VmSize:    13380 kB
VmLck:         0 kB
VmPin:         0 kB
VmHWM:       972 kB
VmRSS:       972 kB
VmData:      220 kB
VmStk:       132 kB
VmExe:       208 kB
VmLib:      2320 kB
VmPTE:        48 kB
VmPMD:        12 kB
VmSwap:        0 kB

You can see total RSS (amount of used RAM) of 972 kB, of which 220 kB is "data" (typically not shared) and 132 kB is stack (also not shared). So each extra bash left running is pretty small.

Some advice: if you're having to do a bunch of workarounds like this... why can't you use cron? That's a simpler, cleaner approach, far less likely to have unexpected bugs (quick! How does sleep 1d handle a daylight saving time change? What happens if your sleep returns early because it was SIGTERM'd as part of a reboot/shutdown?). If your sysadmin is concerned about unauthorized people scheduling cron jobs, point him/her to /etc/cron.allow and /etc/cron.deny; those are documented in crontab(1).

derobert
  • 109,670
  • Thank you for the detailed answer, very interesting! This helps a lot and I am glad I finally asked this question (been bugging me for sometime, I checked a few questions here like this. I will check these out tomorrow. About using cron, I'd really love that too. But I have no idea why it is blocked (for everyone, not only me). – mathB Nov 01 '17 at 17:20
  • I found the answer to why I'm not able to use cron here. I checked the three processes that I'm running in the background and they use 1MB, 4MB and 6MB respectively. Interesting to note about the daylight saving, which is approaching in a few days. Guess I'll know soon. And thanks for the advise, I'll try and contact my sysadmins to see if they can enable cron. – mathB Nov 02 '17 at 07:35