[Bug 239027] emulators/virtualbox-ose: vm based delay not ties to the boot or shutdown process

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Sun Jul 7 00:23:35 UTC 2019


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239027

            Bug ID: 239027
           Summary: emulators/virtualbox-ose: vm based delay not ties to
                    the boot or shutdown process
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: Individual Port(s)
          Assignee: vbox at FreeBSD.org
          Reporter: dereks at lifeofadishwasher.com
             Flags: maintainer-feedback?(vbox at FreeBSD.org)
          Assignee: vbox at FreeBSD.org

Using vboxheadless_<machine>_delay in rc.conf will delay the start/stop of a
given VM however this delays the whole boot or shutdown process depending when
headless starts/stops or the order of vboxheadless_machines.

Due to what appears to be an issue, at least on my system, with starting
Windows VMs on zfs via vboxheadless along with other VMs, jails, and the system
with cause the host system to randomly panic/freeze.  Removing these VMs from
vboxheadless I do not see the issue and these VMs can be started post startup. 
 However, now these need to started/stopped manually.

Currently I'm only looking for a startup delay on a VM basis that isn't tied to
the boot process.

It appears this could be solved if a new variable is introduced and an sh
compound statement is given to the daemon command in vboxheadless.in:70 rc
file.


  eval vmdelay_start="\${vboxheadless_${machine}_delay_start:-0}"

  ...
    daemon -f ... ${vmuser} sh -c "{ /bin/sleep ${vmdelay_start}; ...; }
  ...

Creating a stop delay doesn't seem practical unless if it is used as the
current delay.  If a stop is introduce should the current delay be
renamed/removed?

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-ports-bugs mailing list