pve-common/test/Makefile

SUBDIRS = etc_network_interfaces

all:

.PHONY: check install clean distclean

check:
	for d in $(SUBDIRS); do $(MAKE) -C $$d check; done
	./lock_file.pl
	./calendar_event_test.pl

install: check
distclean: clean
clean:
importing etc_network_interfaces tests 2015-06-25 12:54:31 +03:00			`SUBDIRS = etc_network_interfaces`

			`all:`

			`.PHONY: check install clean distclean`

			`check:`
			`for d in $(SUBDIRS); do $(MAKE) -C $$d check; done`
Tools: make file-locking aware of external exception sources Previously an external exception (eg. caused by a SIGARLM in a code which is already inside a run_with_timeout() call) could happen in various places where we did not properly this situation. For instance after calling $lock_func() but before reaching the cleanup code. In this case a lock was leaked. Additionally the code was broken in that it used perl's automatic hash creation side effect ($a->{x}->{y} implicitly initializing $a->{x} with an empty hash when it did not exist). The effect was that if our own time out was triggered after the initial check for an existing file handle inside $lock_func() happened (extremely rare since perl would have to be running insanely slow), the cleanup did: if (my $fh = $lock_handles->{$$}->{$filename}->{fh}) { This recreated $lock_handles->{$$}->{$filename} as an empty hash. A subsequent call to lock_file_full() will think a file descriptor already exists because the check simply used: if (!$lock_handles->{$$}->{$filename}) { While this could have been a one-line fix for this one particular case, we'd still not be taking external timeouts into account causing the first issue described above. 2017-05-11 13:40:02 +03:00			`./lock_file.pl`
test/calendar_event_test.pl: regression tests for PVE::CalendarEvent 2017-05-17 08:18:24 +03:00			`./calendar_event_test.pl`
importing etc_network_interfaces tests 2015-06-25 12:54:31 +03:00
			`install: check`
			`distclean: clean`
			`clean:`