 |
Could you try setting the working explicitly in the bareos-fd.conf ? The error message is printed when no working directory is set which is strange as there is a default compiled into the code so it should always be set. Its also strange we only see this on this platform is on other platforms the working directory still in the configs ? |
|
|
Adding the working directory in the conifg, doesnt work right. Only the error output disappears. And ther are no trace files in the working/pid directory and no running fd. No there is no working directory in the configs anymore. Yeah this problem only exists on ubuntu. root@ubuntu12fresh:/var/lib# bareos-fd -c /etc/bareos/bareos-fd.conf -d200 bareos-fd: filed_conf.c:472-0 Inserting director res: dir-ci-mon ubuntu12fresh: message.c:343-0 Copy message resource f67c48 to f8b178 root@ubuntu12fresh:/var/lib# 08-Feb 13:25 ubuntu12fresh: ERROR TERMINATION at bsys.c:549 Could not open pid file. <NULL>/bareos-fd.9102.pid ERR=Datei oder Verzeichnis nicht gefunden |
|
|
Compiled the code on Ubuntu 12.04 LTS in Virtual box cannot reproduce it there just works. Did find some problems as I didn't have zlib there so this at least gave some fixes. Only way to determine what goes wrong here is to have debugging package and put a debugger on the binary and see what is happening. We also found some problems in the Ubuntu autoconf stuff so that may also help to fix it, but it could be still be broken on this specific platform. |
|
|
It seems, that problem is only triggered, when Bareos is compiled in OBS. Things already tested: - remove optimization (-O2), compile with -O0: same problems as before - compiler version are identical on local testsystem (working) and OBS chroot environment: # dpkg -l | grep gcc ii gcc 4:4.6.3-1ubuntu5 GNU C compiler ii gcc-4.6 4.6.3-1ubuntu5 GNU C compiler ii gcc-4.6-base 4.6.3-1ubuntu5 GCC, the GNU Compiler Collection (base package) |
|
|
|
|
|
I added the config.out from obs, optimization disabled, still not working. |
|
|
|
|
|
and also the full build log. |
|
|
using gdb debugging I have figured out the problem no idea why it happens but the config engine uses function pointers that handle certain conversions e.g. to store a bool, string etc. Those function pointers are stored in the config array and both the default initialization in init_resource but also some other places compare the function pointer in the config table with the actual address of the function to determine what type is being processed. The problem on Ubuntu seems to be that the stored function pointer in the config table smells like a 32 bits pointer but when you ask for the address of the actual function you get a 64 bit pointer so the compare logic woes and as such the default is never set. This also explains why explicitly setting the value doesn't work as there is similar pointer comparison going on there. This smells very much like the new x32 ABI on x86_64. The bacula code because that is where this whole code originates from seems to have problems when pointers have random sizes which seems to be the case. What I can find is that this is enable by the -mx32 option so maybe compiling with explicitly -m64 will solve this problem or we need some more stuff to handle the x32 ABI and when comparing the function pointers we need some macro that truncates the pointer or convert it in the same manner as the ABI does to 32 bit. An other possible solution is adding a type field to the config tables and no longer compare function pointers but that may only solve this particular problem. |
|
|
Ok small misinterpretation on my side as what gdb prints when printing a function pointer and what is printed by gdb when you resolve a functionname. It seems the print of a structure with a function pointer always prints the short representation of the function pointer and the printing of the function pointer directly looks differently but that is normal. What is a problem is that the version build by OBS has a problem where comparing a function pointer doesn't work (watched it with gdb and it just never matches any function pointer, when doing it on a hand compiled version of ubuntu I cannot reproduce this and it just matches the function pointer and jumps into the function as initializes the default value (for all data, the misfiring version fails for all default data not only for the working dir.) It also seems the whole trick used by the config engine by calculating the data offset into the structure doesn't work and that explains why also explicitly setting a value doesn't set the value in the structure.) It must have something to do with the exact compiling options. I first thought it could be related to the special linker flags passed on -Wl,-Bsymbolic-functions -Wl,-z,relro but adding these to the working hand compiled version doesn't result in a non working version. This turns into some kind of needle/haystack search. Its something that you can show in the debugger but there is no clue as to why it happens and why something that has worked for ages now all of sudden does not. |
|
|
Ok wrong test set. The LDFLAGS are the problem !!!! So we should remove the -Wl,-Bsymbolic-functions -Wl,-z,relro |
|
|
Tried disabling the hardening in the debian/rules file but it seems Ubuntu has its own idea on these items and ignores the documented hints. |
|
|
I've compiled Ubuntu now with disabled hardening. Configure outputs: Compiler flags: -g -O2 -Wall -fno-strict-aliasing -fno-exceptions Linker flags: -Wl,-Bsymbolic-functions Libraries: -lpthread -ldl -ldl However the behavior is the same as before. |
|
|
0002-disable-hardening.patch (840 bytes) |
|
|
Patch to disable hardening is attached. There is still the -Wl,-Bsymbolic-functions flags. I'm trying to disable them also. |
|
|
Same problems with: Compiler flags: -g -O2 -Wall -fno-strict-aliasing -fno-exceptions Linker flags: Libraries: -lpthread -ldl -ldl @Marco: do you see anything still wrong with these flags? How can I verify, that a compiled and linked binary is really made with this flags? |
|
|
No flags look ok. After doing some more tests myself I can at will make this appear and disappear by linking the libbareoscfg-13.1.0.so shared library with and without the -Wl,-Bsymbolic-functions So I can for sure say that its related to -Wl,-Bsymbolic-functions Its even so simple that if you change the LDFLAGS in the Makefile and do a rm libbareoscfg.la and then a make it will generate a new shared lib without recompiling any sources and that leads to a working shared lib when you remove the above entry from it. The problem is however you cannot really see any difference in the two generated libraries already tried the obvious nm -p for symbols which look almost the same (small memory offset differences but nothing more) and also objdump -T or objdump -h don't show anything obvious. What you could do is use the attached libbareoscfg-13.1.0.so file which is the correctly compiled version. This version works for me for letting bareos-fd start with bareos-fd -f -d 200 -c ./bareos-fd.conf in the src/filed dir. |
|
|
|
|
|
Installed current OBS 13.1.0 deb packages e.g. only comon (e.g. libs) and filed and that fails. Replacing the libbareoscfg-13.1.0.so file and the same binary works. |
|
|
by setting the LDFLAGS directly before the configure run, we can disable the LDFLAGS. This seems to be the only option that works. That way, we have the jenkins regressions run without problems, only the mysql tests have a problem with access control, but that should be a minor problem. |
|
|
0002-disable-hardening-by-settings-LDFLAGS.patch (904 bytes) |
|
|
with Patch https://bugs.bareos.org/mantis/file_download.php?file_id=7&type=bug it also seems to work. Difference is, that LDFLAGS is now set to a value, instead setting it to blank. What OBS (dpkg-buildpackage) is doing is first call dpkg-buildflags to get the system compiler and linker flags and set them as environment variables. Our debian/rules makefile is executed after this. Setting LDFLAGS to "" looked as it has helped, but the result have been the same. By setting LDFLAGS to some, hopefully safe value, it seems to work. However, I'll take a closer look to it tomorrow, when I'll be in the office again. |
|
|
currently, we have a workaround. Looking for a better solution has a lower priority. |
|
|
make summary more descriptive. |
|
|
Fix committed to bareos master branch with changesetid 1164. |
- Anonymous
