On 06.12.17 23:23, Dave Horsfall wrote:
On Wed, 6 Dec 2017, Jan Bramkamp wrote:
Synth and poudriere are parallel build tools and as such are very
taxing on the system. I suspect your system is unstable under such
load, because of a configuration error or unreliable hardware. One
such configuration error that bit me is tmpfs mounted without size
limitation. Without size limits it can exhaust RAM + swap and crash
the system. Limit the sum of all your tmpfs mounts to significantly
less than RAM + swap.
What happens then? Does the build process merely crash instead? I ask
because my minimal system (all I can afford on my "income") has 512MB
memory (all it will take) ad 1GB swap; building Ruby etc kills it, so I
use packages in that case i.e. no customisation if I wanted it.
In that case I wouldn't use tmpfs at all. One conceptual difference
between the old portmaster/portupgrade tools and the newer tools like
poudriere and synth is that the old tools try to minimize rebuilds by
modifying the live system. This can break the system if the upgrade
fails and will leave it inconsistent while the upgrade runs. Also some
ports misbehave and interact with installed software they didn't list as
dependency if it is installed. For these reasons the new tools create
jail/chroot environments to build ports in a clean environment.
Poudriere is designed around ZFS features (snapshots and cloning). Those
can be emulated with UFS and overlay file systems, but Poudriere works
best on a big ZFS based system with enough RAM to keep the build dirs in
tmpfs (e.g. 8GB RAM per parallel builder and one builder per CPU
core/thread). You can configure poudriere to use a single builder and
UFS, but it will be a slow process.
Synth reduces that overhead somewhat by reusing the host system. Its
focus is more on keeping a single system up to date instead of compiling
sets of ports to custom repos for other systems and the curses UI is a
nice touch. Also synth can try to avoid building ports by prefetching
packages from an upstream repo.
To be honest few FreeBSD devs still care about self hosting FreeBSD on
such tiny systems (0.5GB RAM, 1-2 cores). There are devs interested on
optimizing FreeBSD for small embedded systems but you aren't expected to
rebuild FreeBSD from source on a wireless access point or dedicated
firewall appliance. If you have to compile and value your time get
adequate hardware. Old 2U dual sockets servers may burn a lot of power
but are quite cheap and you don't have to run a compile server 24/7.
_______________________________________________
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
