Running a process at boot up

Don't know, what exactly you're trying to achieve, but there are by principle two ways under FreeBSD to start processes/services/demons when FreeBSD boots.
The easiest way of course is to use cron(8): crontab -e opens the user's editor on his crontab (If you wanna start something as root, well, login as root, and do the same command) Adding a line
Code: 
@reboot  /path/to/my/script.sh
will execute "script.sh" at reboot.
The other way, for more sophisticated/complex/diffentiated jobs, especially to start demons, is rc(8)

For shutdown there is /etc/rc.shutdown:
sh: 
[...]
# Insert other shutdown procedures here

exit 0
 
My solution with bash is to enable autologin (etc/ttys al setting)) and run things that should be executed after startup in ~/.bash_profile if the curremt terminal device is /dev/ttyv0, and it isn't done before, so no /tmp flag file exists.
It's too complicated anyway, There should be a standard for doing this in the system base.
 
MG said:
My solution with bash is
Click to expand...
Of course, this is another way.
But putting things into the shell's start-config (it works with all login shells, not only bash), start things first, when the system is already up and running completely.
For certain things that's quite enough (I start my whole user environment this way.) But depending on what you want to get done, this may not be sufficient, or too late, because you want those jobs already be done or running, when/before you login.
That's depending on what you achieve to do - system/user.
And according to that, you also either chose apart from the login-shell-script, cron, or rc.
 
Maturin said:
Of course, this is another way.
But putting things into the shell's start-config (it works with all login shells, not only bash), start things first, when the system is already up and running completely.
For certain things that's quite enough (I start my whole user environment this way.) But depending on what you want to get done, this may not be sufficient, or too late, because you want those jobs already be done or running, when/before you login.
That's depending on what you achieve to do - system/user.
And according to that, you also either chose apart from the login-shell-script, cron, or rc.
Click to expand...
I also have a custom /etc/rc to start other things before user-level. But I don't agree with it. A ready-to-use base system should have a central configuration for this. It's not a special thing or so. Even the most limited users might require it. Now it's a sysadmin job on request.
 
A user can use their crontab with @reboot to kick something off at boot. That process can be designed to run forever (reading without timeout from a fifo that no one writes to; or just sleep for a really large number of days), and to perform a task on the way out (when killed during shutdown) by trapping on exit in sh, for example.
 
Running something when the machine goes down is not reliably possible, because the different programs have init(8) do different things with the stop part of rc scripts,, if anything.

Why would you want to set a flag to 0 at shutdown only to set it to 1 again on boot?
 
cracauer@ said:
Running something when the machine goes down is not reliably possible, because the different programs have init(8) do different things with the stop part of rc scripts,, if anything.

Why would you want to set a flag to 0 at shutdown only to set it to 1 again on boot?
Click to expand...
You have to include something in kern_shutdown (?) that's executed before the actual ACPI shutdown call. Not sure what's all still available at that point. All storage is gone so you have to do something with the information in memory.
 
MG said:
You have to include something in kern_shutdown (?) that's executed before the actual ACPI shutdown call. Not sure what's all still available at that point. All storage is gone so you have to do something with the information in memory.
Click to expand...
No, just run something that stays running until the shutdown process sends the quit signal to everything that is still running, and clean up on your way out. You should be able to do this with sh and trap.
 
Eric A. Borisch said:
No, just run something that stays running until the shutdown process sends the quit signal to everything that is still running, and clean up on your way out. You should be able to do this with sh and trap.
Click to expand...
Quit signal? It's a wired ACPI shutdown signal. The last thing that happens. If your mainboard has this wire connected, the PSU receives it and shuts down immediately. To ATX standby, unfortunately, but it looks like shutdown.
 
cracauer@ said:
Running something when the machine goes down is not reliably possible, because the different programs have init(8) do different things with the stop part of rc scripts,, if anything.

Why would you want to set a flag to 0 at shutdown only to set it to 1 again on boot?
Click to expand...
Let me restate this more clearly:

You can not rely on something being run at shutdown. Because there is no guarantee that the machine will be shut down. The running operating system can always be stopped dead in its tracks, for example by a CPU fault, by a crash, by a sudden power disruption (which can even happen in laptops), and so on.

Given that you can not rely on something being run at shutdown, the startup process has to be able to deal with starting WITHOUT the thing at shutdown having been run. At this point, why even bother with running anything at shutdown? It is a cleaner design to just do the work needed at startup ... the OS will come down at some point. There is a famous German saying about aviation: "runter kommen sie immer" (they will always come down).

The exception to this is something like fsck: If starting without a clean shutdown is very very costly, then add something at shutdown just to reduce the startup cost. Examples are a file system that while running keeps the on-disk data structures in a dirty state, and promises to fix them during shutdown; if the promise is broken, fsck has to be run. But beware of the risks of such an approach: the "has been shutdown" flag needs to be stored reliably and persistently, and fsck tends to be the most complex and error-prone part of file systems. Better to design your system such that it never needs shutdown, and can always restart.
 
balanga said:
When cron runs at startup would a network drive identified in fstab be already mounted in normal circumstances?
Click to expand...
Look at the rcorder(8) of the scripts; rcorder /etc/rc.d/*. You'll notice /etc/rc.d/cron is somewhere at the bottom, way later than mountcritlocal, FILESYSTEMS, NETWORKING, mountcritremote, automountd and mountlate.
 
What I can imagine as use-cases for such a flag is to confirm previous shutdown is done sanely or not.
If the flag (assume it to create a file on boot and delete on sane shutdown, zero-sized file is sufficient here) is kept ON at startup, it means it was insane shutdown (power outage, intentional power off, intentional cold reboot or any kind of bugs that crashes shutdown process with sudden cold reboot).
 
Maturin said:
The other way, for more sophisticated/complex/diffentiated jobs, especially to start demons, is rc(8)

For shutdown there is /etc/rc.shutdown:
sh: 
[...]
# Insert other shutdown procedures here

exit 0
Click to expand...
The "sophisticated/complex/diffentiated" way is to use an rc.d script for both start-up and shut-down, without editing rc.shutdown.

There are plenty of rc scripts that implement start/stop methods, that can be used as a template - just make sure that the
"# KEYWORD" line includes "shutdown" .
 
Since they seem be avoiding telling us, we can speculate!

We know they asked for something:
  1. That runs at start and stop to record state.
  2. Runs after a network drive would be mounted (and presumably before unmount / loss of connectivity).
Pretty clear the system is a coffee maker, and they want to be able to look at a web page served off the network drive from a different computer to see if the coffee is on or not. They've developed OCCP:// -- Overly Complex Coffee Protocol.

Let's all take a guess and see who is closest! Internet points for the winner.

That said, and with the excellent caveats from ralphbsz, here is something that a user (doesn't have to be someone with elevated privileges) can start with a cronjob and @reboot which has a "start action" and "exiting action" phase. It's designed to block (waiting on a read that never completes / no CPU usage) until killed (catches sigterm) during a shutdown/reboot process.

Bash: 
#!/bin/sh

# Monitor all commands for success; warn on failure.
set -e
trap "echo 'Unable to monitor coffee!' >&2" EXIT

# Catch TERM (what reboot sends) and INT (ctrl-c); do nothing else.
# Need to catch so sh doesn't just exit straight away.
trap true TERM INT

# Make something (f.d. 3) we can read from which will block forever.
fifo=$(mktemp -u)
mkfifo -m 0600 "$fifo"
exec 3<>"$fifo"
# Remove it now; no residue, and prevent anything else from opening it.
rm -f "$fifo"

# vv #### PUT YOUR "WE'VE STARTED" TASKS HERE. ####
echo "[$$] Coffee is hot! :)"
# ^^

# Disable success monitor.
trap - EXIT

# Blocks until TERM/INT signal caught
read _ <&3 >&- 2>&- 3>&-

# vv #### PUT YOUR "WE'RE EXITING" TASKS HERE. ####
echo "[$$] Coffee is cold! :("
# ^^

exit 0
 
Eric A. Borisch said:
That said, and with the excellent caveats from ralphbsz, here is something that a user (doesn't have to be someone with elevated privileges) can start with a cronjob and @reboot which has a "start action" and "exiting action" phase. It's designed to block (waiting on a read that never completes / no CPU usage) until killed (catches sigterm) during a shutdown/reboot process.
Click to expand...
The problem with this is that when sigterm is handled, the rc shutdown scripts have already completed, leaving a system that isn't fully functional. In particular, the OP mentioned a network drive, which, presumably, will have been unmounted.
 
bob2112 said:
The problem with this is that when sigterm is handled, the rc shutdown scripts have already completed, leaving a system that isn't fully functional. In particular, the OP mentioned a network drive, which, presumably, will have been unmounted.
Click to expand...
That's a valid concern, but it looks to me like unmounting things is done by the kernel, called from init after it has already finished rc.shutdown and has sent TERM and KILL signals (with 10s wait between) to all remaining processes.

If you look at the shutdown step for /etc/rc.d/mountcritlocal, for example, it is to just call 'sync'. Likewise mountcritremote has stop_cmd=":". (Do nothing.)

So YMMV, but I think it'll be OK.
 
Eric A. Borisch said:
That's a valid concern, but it looks to me like unmounting things is done by the kernel, called from init after it has already finished rc.shutdown and has sent TERM and KILL signals (with 10s wait between) to all remaining processes.

If you look at the shutdown step for /etc/rc.d/mountcritlocal, for example, it is to just call 'sync'. Likewise mountcritremote has stop_cmd=":". (Do nothing.)

So YMMV, but I think it'll be OK.
Click to expand...

I was actually looking at nfsclient, which has: stop_cmd="unmount_all"

However, I gather that enabling nfsclient is optional, and the comment suggests that the meaning of unmount_all might not be as straightforward as it sounds.


unmount_all()
{
# If /var/db/mounttab exists, some nfs-server has not been
# successfully notified about a previous client shutdown.
# If there is no /var/db/mounttab, we do nothing.
if [ -f /var/db/mounttab ]; then
rpc.umntall -k
fi
}
Click to expand...
 
You must log in or register to reply here.
Back
Top