My Gixxer

Might be a bit late to blog something about a bike I bought more than a year ago, but they always say "better late than never", so here goes ...

Early 2011, I had an accident with the CBR. The costs to fix it were too high, so it was declared a total loss :-( Fortunately I always wear full protection, and because of that I didn't have any serious injuries. The car hit me with it's front directly on the Puma 1000 boot on my right leg. Can't think of what would have happened to my leg and foot, if I was wearing shoes instead.




How to really flush the various nscd caches

Since I keep finding posts that tell you to restart nscd to flush its caches, I'll tell you how to really do it.

The nscd caches are saved to disk, On my Fedora system, they are located in /var/db/nscd:

[root@dev402 ~]# ls /var/db/nscd/
group hosts netgroup passwd services

When you stop nscd, these files will just stay there, so restarting really doesn't flush your nscd caches.
What you need to do is use the --invalidate option, e.g.:

nscd --invalidate=hosts




Samba 3.5 on dual-stack Linux systems

It seems that Samba 3.5 has problems binding it's socket when running on dual-stack Linux systems. This is what I am seeing in log.smbd, right after starting Samba:

[2011/11/30 18:42:18, 0] smbd/server.c:1141(main)
smbd version 3.5.11 started.
Copyright Andrew Tridgell and the Samba Team 1992-2010
[2011/11/30 18:42:20.269303, 0] smbd/server.c:501(smbd_open_one_socket)
smbd_open_once_socket: open_socket_in: Address already in use
[2011/11/30 18:42:20.269350, 0] smbd/server.c:501(smbd_open_one_socket)
smbd_open_once_socket: open_socket_in: Address already in use

I am seeing this on at least 3 different Linux distributions:

  • CentOS 6.0 x86_64, samba-3.5.4-68.el6_0.2.x86_64
  • Gentoo 10.0 x86_64, net-fs/samba-3.5.11



cron.daily on SLES

Have you ever noticed that if you put cron jobs in /etc/cron.daily on a SLES machine, they seem to run at random times? I noticed it a few times, and I find it to be really annoying. Say, I rebooted a machine yesterday around 14:00, and today at 14:15, the machine starts rebuilding the man db, backing up the rpm db, cleaning /tmp, rotating logs, etc. Huh?! Looks like a bad idea to do such things when the system is currently in use by multiple people. Imagine that you put a database backup in there, and that backup locks your database...

Well, this actually is a feature. If you read /etc/sysconfig/cron, you'll find this piece of text:

# At which time cron.daily should start. Default is 15 minutes after booting
# the system. Example setting would be "14:00".




Subscribe to RSS - blogs