Odi's astoundingly incomplete notes

If your Oracle database does not register with the listener, you get ORA-12505. Normally the DB registeres automatically after a while. But you can force it to do that.

As SYS:

ALTER SYSTEM REGISTER;

However, if it did not register automatically, chances are that this does not help either.

Check the listener status:

lsnrctl status

Check the listener's log file (filename is in the status output).

Check which listener the DB wants to register with:

select name, value from v$parameter where name in ('local_listener', 'remote_listener');

This gives you a TNS name. Check that this TNS name is defined in $ORACLE_HOME/network/admin/tnsnames.ora Such an entry looks like:

LISTENER_SID = (ADDRESS = (PROTOCOL = TCP)(HOST = oracle.example.com)(PORT = 1521))

posted on 2018-09-12 15:09 CEST in Code | 0 comments | permalink

In Oracle 12.2.0.1 the following call leaks an imageio file in /tmp. Not nice.

ORDImage.processCopy(pImageBlob, 'maxscale='100 100', destBlob);

posted on 2018-08-29 13:38 CEST in Code | 0 comments | permalink

Have you ever seen GUI code that has no leaks? Me neither.

posted on 2018-08-20 11:14 CEST in Code | 0 comments | permalink

Are they sure they want to run all sorts of crap as root without any limits?

top - 15:12:11 up 12 min,  1 user,  load average: 98.10, 40.27, 17.04
Tasks: 271 total, 112 running, 159 sleeping,   0 stopped,   0 zombie
%Cpu(s): 17.0 us, 81.7 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.7 hi,  0.6 si,  0.0 st
GiB Mem :    0.113 total,    0.008 free,    0.066 used,    0.039 buff/cache
GiB Swap:    2.000 total,    1.801 free,    0.199 used.    0.006 avail Mem

  PID USER      PR  NI    VIRT    RES %CPU %MEM     TIME+ S COMMAND                                                             
 8000 root      20   0   61.2m   4.8m  1.1  4.2   0:00.79 R synoscgi_SYNO.Core.Package.Thumb.Server_1_get                       
 8014 root      20   0   61.2m   4.8m  1.1  4.2   0:00.79 R synoscgi_SYNO.Core.Package.Thumb.Server_1_get                       
 8020 root      20   0   61.2m   4.8m  1.1  4.2   0:00.80 R synoscgi_SYNO.Core.Package.Thumb.Server_1_get                       
 8022 root      20   0   61.2m   4.8m  1.1  4.2   0:00.78 R synoscgi_SYNO.Core.Package.Thumb.Server_1_get                       
 8024 root      20   0   61.2m   4.8m  1.1  4.2   0:00.78 R synoscgi_SYNO.Core.Package.Server_1_get_timestamp                   
 8025 root      20   0   61.2m   4.8m  1.1  4.2   0:00.85 R synoscgi_SYNO.Core.Package.Thumb.Server_1_get                       
 7994 root      20   0   61.2m   4.8m  1.1  4.2   0:00.74 R synoscgi_SYNO.Core.Package.Thumb.Server_1_get                       
 7995 root      20   0   61.2m   4.8m  1.1  4.2   0:00.85 R synoscgi_SYNO.Core.Package.Thumb.Server_1_get    

posted on 2018-08-16 15:16 CEST in Code | 0 comments | permalink

Gentoo has given more love to its sys-firmware/intel-microcode package. It's now easier than ever to update microcode automatically early on boot. This is a valuable alternative to shipping microcode within the BIOS. I mean honestly, who regularly checks for BIOS updates? Much easier by doing that through an ebuild.

The new USE flag initramfs now builds a cpio archive at /boot/intel-uc.img ready to be used by grub. In /boot/grub/grub.cfg:

menuentry 'Gentoo Linux 4.14' {
  root=hd0,1
  linux /boot/linux-4.14.12 root=LABEL=ROOT ro rootfstype=ext4 net.ifnames=0
  initrd /boot/intel-uc.img /boot/initrd.img
}

Note how the microcode intitramfs is simply prepended to the boot initramfs (initrd). A kernel that has microcode laoding support enabled will find it there, upload the microcode into the cpu and then discard the initramfs blob, and continue booting with the initrd.img. The first line in your dmesg output will show:

microcode: microcode updated early to revision 0x80, date = 2018-01-04

posted on 2018-01-15 10:10 CET in Code | 0 comments | permalink

Gentoo has new profiles that require you to "recompile everything". That is technically not really necessary. Only static libraries really need recompiling.

Here is why:
A static library is just an archive of .o files (similar to tar), nothing more, and linking against a static library is roughly the same as just adding more .o files to the linker line. You can also link a static library into a shared library - the code in the static library is then just copied into the shared library (but the code then must be compiled with -fPIC, as with all other code that is used in shared libraries).

You can find static libs like so:

equery b $(find /usr/lib/ /lib/ -name *.a) | awk '{ print $1; }' | sort | uniq

Typically this yields packages like elfutils, libbsd, nss, iproute2, keyutils, texinfo, flex, db, numactl.


posted on 2017-12-07 11:59 CET in Code | 0 comments | permalink

Your latest emerge -uavD @world may result in the following error:

# required by sys-apps/portage-2.3.13-r1::gentoo[python_targets_python3_4,-build,python_targets_python2_7,-python_targets_python3_5]
# required by virtual/package-manager-0::gentoo
# required by @system
# required by @world (argument)
>=dev-python/pyblake2-0.9.3-r1 python_targets_python3_4

That's because python-3.5 as well as python-3.6 and a new version of portage went stable, that in turn causes python USE flag changes and portage can't figure out correctly what to do.

Solve this by manually installing python-3.5 (only) first and recompiling the resulting USE flag changes:

emerge -1av python:3.5
eselect python update
emerge -1avD --changed-use @world

That should let you update world again and depclean will remove python-3.4 for you.

emerge -uavD @world
emerge --depclean

posted on 2017-12-05 11:37 CET in Code | 0 comments | permalink

I noticed that Firefox was not playing any sound any more. Apparently pulseaudio stopped working. Manually running pa showed the following error:

xmalloc.c: Assertion 'size < (1024*1024*96)' failed at /var/tmp/portage/media-sound/pulseaudio-10.0/work/pulseaudio-10.0/src/pulse/xmalloc.c:72, function pa_xmalloc0(). Aborting.

This means it is trying to allocate a ridiculous amount of memory.

Looking at the backtrace in gdb reveals:

(gdb) bt
#0  0x00007ffff6a5ef50 in raise () from /lib64/libc.so.6
#1  0x00007ffff6a60bfa in abort () from /lib64/libc.so.6
#2  0x00007ffff7914b32 in pa_xmalloc0 () from /usr/lib64/libpulse.so.0
#3  0x00007ffff7ba1db1 in pa_database_open () from /usr/lib64/pulseaudio/libpulsecore-10.0.so
#4  0x00007fffeed60468 in module_card_restore_LTX_pa__init () from /usr/lib64/pulse-10.0/modules/module-card-restore.so
#5  0x00007ffff7b5ac98 in pa_module_load () from /usr/lib64/pulseaudio/libpulsecore-10.0.so
#6  0x00007ffff7b49751 in ?? () from /usr/lib64/pulseaudio/libpulsecore-10.0.so
#7  0x00007ffff7b4fd2c in pa_cli_command_execute_line_stateful () from /usr/lib64/pulseaudio/libpulsecore-10.0.so
#8  0x00007ffff7b50551 in pa_cli_command_execute_file_stream () from /usr/lib64/pulseaudio/libpulsecore-10.0.so
#9  0x0000000000406e55 in main ()

So it is trying to read some database. What database?

strace tells us quickly:

open("/home/xoxo/.pulse/91b2f1e2678a89a9c38b83075061a39a-card-database.x86_64-pc-linux-gnu.simple", O_RDONLY|O_CLOEXEC) = 9

So likely this thingy is corrupt. Solved this with:

rm -rf .pulse



posted on 2017-12-01 15:05 CET in Code | 0 comments | permalink

An LWN article suggests to disable maximum mount count. I do the opposite. I fsck on each boot. fsck on ext4 is very fast these days even on large filesystems. If you are like me and run the latest kernel it may save your butt from fs regressions that do sometimes happen.

tune2fs -c 1 /dev/disk/by-label/ROOT

posted on 2017-07-27 14:28 CEST in Code | 0 comments | permalink

Mapped the eject key of my old iMac to the following script to rate limit it:

#!/bin/sh
L="/tmp/eject.lock"
[ -e $L ] || touch $L
exec 3<$L
flock -n 3 || exit
eject "$@"
sleep 5

Because I found it really annoying when the kids fill the keyboard buffer with eject events that take forever to be processed.
posted on 2017-07-24 22:02 CEST in Code | 0 comments | permalink