Brew afsctool on your own for Mac OS Sierra

Recently, I came across an error message while compressing the document with HFS+ compression using open source tool afsctool. The repository on Homebrew project is still on version 1.6.4.

Message comes up every time: "Unable to compress file."

Someone on Github has figured out what's happening and has a solution. The Github user has pointed out that the filesystem on Sierra returns a different value of file type than its predecessor. This renders afsctool useless and return error message at all time. But the suggested change has never been updated on the original source repository of afsctool.

With a little patience for not using this tool, I made up my mind. I think it's time to homebrew our software tool before the Author patches the source code for this.

Here's the recipe:

Before your own compiling work, you might want to uninstall the outdated brew formula for afsctool:

$
$ brew uninstall afsctool

Make sure gcc is installed properly on your Mac.

Take a look at the Hombrew formulas for afsctool via http://brewformulas.org/Afsctool

Take a look at the source file from there: https://github.com/Homebrew/homebrew-core/tree/master/Formula/afsctool.rb

We found a URL from there: https://docs.google.com/uc?export=download&id=0BwQlnXqL939ZQjBQNEhRQUo0aUk

Also, take a look at the parameters called from the def() function call. Highlighted parameters will be useful for compiling:

def install
    cd "afsctool_34" do
      system ENV.cc, ENV.cflags, "-lz",
         "-framework", "CoreServices", "-o", "afsctool", "afsctool.c"
      bin.install "afsctool"
    end
end

Grab the source code ZIP of afsctool from the above URL.

Extract the ZIP file to a temporary location.

Find afsctool.c and amend the file according to this Github post.

Try compiling the .c file afsctool.c with GCC compiler using the aforementioned parameters from brew formula:

$
$ gcc -lz -framework CoreServices -o afsctool afsctool.c

Copy the compile file afsctool to the common bin folder for easy access:

$
$ cp ./afsctool /usr/local/bin/afsctool

Well, it's time to have a try on our new compiled tool:

$ afsctool -cv ./afsctool.c
/afsctool_34/afsctool.c:
File content type: public.c-source
File size (uncompressed data fork; reported size by Mac OS 10.6+ Finder): 79339 bytes / 79 KB (kilobytes) / 77 KiB (kibibytes)
File size (compressed data fork - decmpfs xattr; reported size by Mac OS 10.0-10.5 Finder): 13396 bytes / 16 KB (kilobytes) / 16 KiB (kibibytes)
File size (compressed data fork): 13412 bytes / 16 KB (kilobytes) / 16 KiB (kibibytes)
Compression savings: 83.1%
Number of extended attributes: 4
Total size of extended attribute data: 50 bytes
Approximate overhead of extended attributes: 1608 bytes
Approximate total file size (compressed data fork + EA + EA overhead + file overhead): 18306 bytes / 18 KB (kilobytes) / 18 KiB (kibibytes)

Finally, the compression works again.

By the way, we may need to keep watching until one day an updated brew formula is available to tackle this problem for Sierra.

Windows 2012 ports exhausted under heavy load

For a test case scenario, I have encountered a port depletion on Windows 2012 server which has its available ports used up quickly due to frequent queries to the database and HTTP requests to web server. Thing happened within a short period of time and nothing can ease the situation except a system reboot. Too many ports are opened but not closed properly which could be mainly due to the arriving order of incoming packets being out of sync.

Here's the extract of resolution:

On Windows platforms, the default timeout is 120 seconds, and the maximum number of ports is approximately 4,000, resulting in a maximum rate of 33 connections per second. If your index has four partitions, each search requires four ports, which provides a maximum query rate of 8.3 queries per second.

(maximum ports/timeout period)/number of partitions = maximum query rate

If this rate is exceeded, you may see failures as the supply of TCP/IP ports is exhausted. Symptoms include drops in throughput and errors indicating failed network connections. You can diagnose this problem by observing the system while it is under load, using the netstat utility provided on most operating systems.

To avoid port exhaustion and support high connection rates, reduce the TIME_WAIT value and increase the port range.

This problem does not usually appear on UNIX systems due to the higher default connection rate in those operating systems.

To set TcpTimedWaitDelay (TIME_WAIT):

    Use the regedit command to access the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\TCPIP\Parameters registry subkey.

1.     Create a new REG_DWORD value named TcpTimedWaitDelay.
2.     Set the value to 60.
3.     Stop and restart the system.

To set MaxUserPort (ephemeral port range):

    Use the regedit command to access the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\TCPIP\Parameters registry subkey.

1.     Create a new REG_DWORD value named MaxUserPort.
2.     Set this value to 32768.
3.     Stop and restart the system.

Furthermore, you may have to set another parameter StrictTimeWaitSeqCheck as well, for TcpTimedWaitDelay to be of effect:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"StrictTimeWaitSeqCheck"=dword:00000001

Setting or changing these will require a reboot for the changes to be in effect.

MySQL CLI mode localhost ignoring --PORT option

I have a issue like this in the past, either in Java or PHP, but never dug into the details of how MySQL server treats its command-line options for Localhost connection.

Basically, Localhost would point to local machine and implicitly means local IP like 127.0.0.1.

For standard MySQL instance, port number is default to 3306. To connect MySQL on different port number is possible by changing port number directly. However, such behaviour is a little bit different on Localhost connection.

Even MariaDB shares common bugs/features with its variant MySQL.

When connecting to MySQL instance on Localhost, you can type the followings with success:

> mysql -uuser -p -hlocalhost -P3306
> mysql -uuser -p -hlocalhost -P3307
> mysql -uuser -p -hlocalhost -P80
> mysql -uuser -p -hlocalhost -P443

They will absolutely redirect you to the instance Localhost:3306. I think of this a bug, yet someone has got an explanation on the official site for years:

On Unix, MySQL programs treat the host name localhost specially, in a way that is likely different from what you expect compared to other network-based programs. For connections to localhost, MySQL programs attempt to connect to the local server by using a Unix socket file. This occurs even if a --port or -P option is given to specify a port number. To ensure that the client makes a TCP/IP connection to the local server, use --host or -h to specify a host name value of 127.0.0.1, or the IP address or name of the local server. You can also specify the connection protocol explicitly, even for localhost, by using the --protocol=TCP option.

MySQL is based on Unix development source so behaviour will follow even when it's complied to Windows release.

To reach one particular port number on Localhost, we must specify the actual IP address. This ensures MySQL connection is done through TCP protocol rather than socket file.

In other words,

> mysql -uuser -p -hlocalhost -P3306 --protocol=TCP
> mysql -uuser -p -hlocalhost -P3307 --protocol=TCP
> mysql -uuser -p -hlocalhost -P80 --protocol=TCP
> mysql -uuser -p -hlocalhost -P443 --protocol=TCP
> mysql -uuser -p -h127.0.0.1 -P3306
> mysql -uuser -p -h127.0.0.1 -P3307
> mysql -uuser -p -h127.0.0.1 -P80
> mysql -uuser -p -h127.0.0.1 -P443

This will make sure we connect to Localhost on the port number as specified.

Ref: https://dev.mysql.com/doc/refman/5.7/en/connecting.html

Fix Acer Aspire ONE Ubuntu "Freezing" Issue (Ubuntu 14.04, 16.04)

Previously, I was looking at Official Ubuntu help page for Acer Aspire series for help but it didn't really work at all. It told us to set the following:

intel_idle.max_cstate=3

I have turned to add the following option to the boot parameters to solve system freezing when the power is connected:

intel_idle.max_cstate=1

Just add it to the GRUB_CMDLINE_LINUX_DEFAULT string in /etc/default/grub.

$
$
$ sudo update-grub
$ sudo reboot now
$
$

c_state = 1 makes CPU running at full power and not falling asleep anymore. It's such a power hunger setting for battery life but it fixed the random freeze issue.

For more advanced option of C state which may suits different CPUs categories. Please check:
http://www.hardwaresecrets.com/everything-you-need-to-know-about-the-cpu-c-states-power-saving-modes/

Quick and dirty reboot of remote Linux server

It sounds annoying sometimes when I was rebooting the remote Linux server, especially on the Cloud. After issuing command like:

$
$ reboot now

The terminal session will definitely be disconnected but the server still hangs in the middle of the termination process and would not boot-up.

We can hard reset the machine if we are sitting in front of it. Holding down [Alt] and [SysRq] (which is the Print Screen key) while slowly typing keys R, E, I, S, U, B will get you safely restarted. Meanings of the keys as follows:

•     R: Switch the keyboard from raw mode to XLATE mode
•     E: Send the SIGTERM signal to all processes except init
•     I: Send the SIGKILL signal to all processes except init
•     S: Sync all mounted filesystems
•     U: Remount all mounted filesystems in read-only mode
•     B: Immediately reboot the system, without unmounting partitions or syncing

For the cloud server, we definitely need some sort of Terminal commands to put the server strictly into reboot process no matter what process is currently running or hanging. At least, we can diagnose it after it boots up again.

$
$ echo 1 > /proc/sys/kernel/sysrq
$ echo b > /proc/sysrq-trigger

First command mimics the keystroke of System Request [SysRq] key and the second one mimics hitting [b] key.

So, [b] for what? It does immediately reboot the system, without unmounting partitions or syncing

So just be prepared, you may suffer any data loss afterwards. However, it's really useful at the time you want to make sure the server does reboot immediately.

*A suggestion would be manually stopping major services and processes before you issue such commands.