Michael Peppler
Sybase Consulting
Sybase on Linux
Install Guide for Sybase on Linux
General Sybase Resources
General Perl Resources
BCP Tool
Bug Tracker
Mailing List Archive
Downloads Directory
Sybase on Linux FAQ
Sybperl FAQ
Michael Peppler's resume

ASE on Linux FAQ

Index of Sections

• Sources and general information

The information on this page has been gleaned from the ASE on Linux list ( which is generously hosted by the International Sybase User Group, as well as from the news:// newsgroup.

The mailing list is archived and searchable at thanks to Aaron Ross.

The ASE on Linux home is at You can download the current free release of ASE for linux directly from there.

Henrik Fuxelius has put together a short "how to" for installing ASE on Linux Slackware 3.6. The document is at

In a recent post to the ASE on Linux mailing list, Teresa Larson listed the major other Sybase-related resources that are available on the net:

Well, the ase-linux list will also help with questions/problems/issues on the Sybase server itself -- it's not a Linux-only list as Luc's response shows. :-)

As for other resources, for self-help, Sybase provides their documentation on-line at

Other forums where you can post Sybase questions are:

comp.databases.sybase - This is a public usenet news group. It's been around for a long time and you'll find people with lots of experience as well as some really nice Sybase engineers participating.

SYBASE-L - This is a listserver mailing list that has been around for years. Like comp.databases.sybase, you'll find people with lots of experience along with really nice Sybase engineers. To join the list, send a SUBSCRIBE message (SUBSCRIBE SYBASE-L ur_firstname, ur_lastname) to LISTSERV@LISTSERV.UCSB.EDU - This site is hosted by Sybase and has forums for a variety of topics (e.g., ase.general, ase.administration, ase.linux, ase.unix, powersoft.public.jaquar.cts, powersoft.public.powerbuilder.general ...). The site has instructions on how to set up your browser to access the news groups.

Those are the biggies. I hope it helps.

Another resource that you should look for is the Sybase FAQ that includes a lot of information on various topics concerning Sybase.

I have written a simple system pre-requisite checker that you can run prior to installing ASE 12.5.x or later to validate that your OS configuration is correct - better to find out about any problems before starting the install...
The script is at

• Where do I get the software?

The current free release of Adaptive Server Enterprise for linux is available for download from
You will be asked to fill in a simple registration form after which you can proceed with the download.

• Connecting to the server

There is a TCP/IP bug in the 2.0.xx linux kernels, where xx is lower than 36. This bug has been fixed by Alan Cox for the 2.0.36 kernel.
If you need to connect to the server from a different machine you should be running the 2.0.36 kernel, or the 2.1.122 (or later) development kernel.

You can download the kernels from This site is widely mirrored, and you can reach a site closer to you by changing the us in the hostname to your country code (au for Australia, uk for the UK, fi for Finland, etc.)
Note that this site can also be accessed via http at

It is only necessary to upgrade the kernel on the machine that is running the server. Clients can run earlier versions of the kernel with no problems.

• Configuring memory

By default the linux kernel is limited to 32 megabytes of shared memory. You will need to increase that value in order to install Sybase ASE.

For 2.4.x kernels the simplest way is to edit /etc/sysctl.conf, and add a kernel.shmmax line. The running /sbin/sysctl -p applies the changes (and the changes get applied automatically at boot). My /etc/sysctl.conf has the following line:

kernel.shmmax = 268435456
which sets the maximum shared memory segment to 256MB.

You can also update the value in the /proc filesystem directly, via the following command:

echo 268435456 > /proc/sys/kernel/shmmax
You can place this command in /etc/rc.d/rc.local (or its equivalent on your system) to have this run at boot.

The following is only valid if you are still using a 2.0.x kernel:

If you are using a 2.0.x kernel, you need to edit /usr/src/linux/include/asm/shmparam.h and change the line that says

#define SHMMAX 0x2000000 /* max shared seg size (bytes) */


#define SHMMAX 0x4000000 /* max shared seg size (bytes) */

which would increase the maximum size of the shared memory segment to 64 megabytes.

In addition it seems that linux by default will only recognize 64 megabytes of RAM. To go beyond that you have to add a "mem=" entry to the lilo.conf file, and then run lilo for it to take. One correspondant tells me he has 256 MB RAM on his linux box, and his lilo.conf looks like this:


Note the append="mem=256M" line in extract above.

• Sybase rc scripts and IDENTITY columns

The rc scripts that are provided with the ASE and 11.9.2 releases use the killproc facility to kill the servers when you execute the stop command (eg, on RedHat /etc/rc.d/init.d/sybase stop) It turns out that this essentially tells the server to perform a shutdown with nowait, which has negative effects on any IDENTITY columns in your databases (ie causes large gaps in the values that are generated).
The fix for this is to change the stop section in the sybase rc script to perform a real shutdown instead of calling killproc. Change
	echo -n "Shuting down Sybase ASE configured servers: "
	killproc dataserver
	killproc backupserver
	killproc monserver

	# Add your own openserver applications.
       echo -n "Stopping Sybase SQL Server"
       $SYBASE/bin/isql -Usa -P******* -S$DSQUERY <<STOPIT
shutdown SYB_BACKUP with nowait

	killproc monserver

	# Add your own openserver applications.
Obviously you need to edit the above to set the password to isql correctly, and you need to make sure that $DSQUERY is set correctly in the script (or you may want to hard code it). You also need to duplicate the code if you have more than one SQL Server running.
Mike Chachich has pointed out to me that this shutdown technique might not work well (or might take a long time) on a very busy system. He suggests issueing checkpoint requests for each database, kill all user processes and then issue a shutdown after all user processes have exited. You would have to write a small script (perl, anyone?) to do this, but it should be fairly simple to do.

• Raw disk I/O

Raw disk I/O is available with ASE and ASE 12.5 and later. It is NOT available when using ASE 11.9.2.

The 11.9.2 and later releases use the O_SYNC flag for all the open(2) calls when using filesystem devices, which forces the kernel to flush the data from the filesystem cache to disk after each and every write. This entails a significant performance hit, and can be controlled on a per-device basis via the sp_deviceattr stored procedure using the dsync option.

In addition, chattr +S <file> forces the O_SYNC flag to be used for a file regardless of whether ASE has it enabled on not.

• Raw disk I/O doesn't work (RH 6.2, RH 7.x, SuSE...)

When Wim added Raw IO support to ASE the beta Raw IO kernel patch for RH 6.1 was using a specific device layout, which the RH engineers then saw fit to change for RH 6.2 and later releases. SuSE and maybe others also follow this device layout.

In RH 6.1 the Raw device administration to bind devices was via /dev/raw. In RH 6.2 (and later) RH decided to reorganize this, using /dev/rawctl for the device binding and a /dev/raw directory to hold the raw devices.

sybinit tries to use the original /dev/raw for binding the devices and a /dev/sybase directory for the devices themselves, which fails under RH 6.2 and later.

This can be fixed like this:

First, become root (and be careful what you do next!)

Go to the devices directory

     # cd /dev
Make sure no raw device binding is active, and no servers that depend on this stuff are running.

Move the 'raw' directory to 'sybase':

     # mv raw sybase
Create a symbolic link for the administration device
     # ln -s /dev/rawctl /dev/raw
Make sure you have the access permissions to the bind device, raw devices and the partitions that are bound to raw devices set correctly. You should follow the instructions from the CONFIGURE file from here.

Now if you restart sybinit it should automatically detect the device size for the raw device bound to the partition that you want to use as master device (or whatever...)

• Building Sybtcl on linux

Sybtcl builds 'out of the box' on Linux, assuming you have Tcl/Tk installed. Tcl 8.0 or higher is recommended. RedHat versions 5.1 and higher include Tcl/Tk 8.0 as .rpm files.

To build Sybtcl, simply unpack the Sybtcl distribution, change to the sybtcl-2.5/unix directory, and:

configure make make install

You must be 'root' to install into the /usr directories.

To install Wisqlite, simple copy 'wisqlite' from the ./samples directory to /usr/bin. Edit /usr/bin/wisqilite and change the top line to:


• Connecting from Win NT/95/98

See the Draft HOW-TO on Connecting from Windows Clients by Shaun Lipscombe for a fairly complete write-up.

Sybase normally distributes the Windows client libraries when you buy a server for any platform.
The 11.9.2 release for linux includes the PC client tools (including Sybase Central) and these can be used to connect to the linux server. I'm not 100% sure what the licencing issues are with this package - you can download the Win32 client, but this is theoretically for development use only. You are supposed to pay a licence fee for production use (at least for the server - again I don't know what the situation is exactly for the Win32 client tools - Contact Sybase if you are in doubt.)
These files are available from
Geoff Winkless reports that when he tried to use these libs he was missing the ctl3d32.dll DLL, but that this file is on the Windows distribution CD.

There are ODBC drivers are available from Openlink software at and you can also use the MS-SQL drivers if you configure the Sybase data source as follows (submitted by Carol Lerche)

Using MSSQL's client support to access Sybase ASE on Linux:

First, realize that some applications/tools (such as the MS SQL isql.exe) use the MS/SQL version of dblib directly, and some (such as Perl DBI) use it through ODBC, so you probably should start by configuring the Sybase server as a MS/SQL dblib client.

STEP 1: Execute the SQL Server Client Configuration Utility (could appear in the Microsoft SQL Server 6.5 program group on your start menu if that's the version you are running).

STEP 2: Under the 'Advanced' tab name your Linux/ASE server something meaningful in the 'Server' field, eg MS2LINUX. In the DLL Name tab, select 'TCP/IP Sockets'. In the Connection String field, enter the DNS name and port matching your Linux ASE machine and its interface file. Port number should be separated by a comma from the DNS name. E.g.,2345
Note that it doesn't matter which port you use, so long as you make it match the port that Sybase is using on the Linux side, as specified in your interfaces file.

Press the "Add/Modify" button to add this entry to the Advanced Client Options list box. This creates a registry entry under HKEY_LOCAL_MACHINE->SOFTWARE->Microsoft->MSSQLServer->Client->ConnectTo with the name you gave (e.g. MS2LINUX) and a value of "DBMSSOCN,,2345" (assuming your dll for TCP/IP sockets is named the same as mine).

STEP 3: (Here, I'm describing the NT procedure...there may not be a distinction between user and system DSN in Windows 9x). Under "Settings--Control Panels--ODBC" select the User DSN or System DSN tab depending on whether only the logged on user or all NT users on this machine should see the data source. Press the Add button.

STEP 4: In the resultant "Create New Data Source" window, select "Microsoft SQL Server" or "SQL Server" (these are synonyms on my system). Press Finish.

STEP 5: Supply a Data Source Name and Description (the name is arbitrary, and doesn't need to match anything else, but should presumably be mnemonic). Pull down the Server selection and choose the server you configured in Step 2. This should properly set the Network Address field as ",2345" and the Network Library field to DBMSSOCN (or "(default)") as well. Do not select "Use trusted connection". Press OK or...

STEP 6 (optional): Press the Options button to configure a specific database name, choose a language, and/or select other options. Dismiss this window when you're done.

What won't work after you do this: any tool that has built in knowledge of the details of MS/SQL server's platform-specific DDL/DML/SQL and generates this for you through a GUI will eventually send the wrong SQL if you try enough database administration functions. Also, we were unable to make a Java JDBC client work against Sybase using the MS/SQL ODBC drivers, although Perl DBI:ODBC does appear to work.

• Date Formats

This is for the 10.0.4 version of OpenClient (ie the one that is included in the free release.)
There is what I consider a bug in the locale handling of OpenClient on linux. By default, when doing a "select getdate()" you get only "01/15/99" in the result, instead of the more normal "Jan 14 1999 7:50AM" format that you normally get on other platforms. This can be fixed (somewhat) by editing /opt/sybase/locales/us_english/iso_1/common.loc and commenting out the

Another option is to change the default date conversion format by using the OpenClient API (e.g. cs_dt_info() for Client Library). Sybperl provides access to this function, as does DBD::Sybase.

• Sybase Central on linux

Sybase 11.9.2 includes the Sybase Central GUI admin tool, but only for Win32 machines. For a native linux app you should check out Like Sybase Central a freeware tool developped by Pascal Ginola, available from

As of ASE 12.5 Sybase Central is written in Java, and runs fine under linux. It is included in the 12.5 release.

• Placing tempdb on a RAM disk

First, add RAM disk support to your kernel by setting CONFIG_BLK_DEV_RAM = 1. This can be done by running make menuconfig or make xconfig in the /usr/src/linux directory and enabling RAM disk support in the Block Devices section.
You need to rebuild your kernel for this to take effect.

Stefan Goebel wrote this on sybase.public.sqlserver.linux:

  • 1. The default max size of a RAM disk is 20mb. You probably want to increase this by setting rd_size in drivers/block/rd.c from 204800 to 102400 (for a 100mb max size, for example).

  • 2. Create the RAM disk, mount it, and then create the new Sybase device for tempdb. Something like this should work to create the filesystem:
       troll#>  /sbin/mke2fs -q -m0 /dev/ram 52000 -F > /dev/null
       troll#>  /bin/mount /dev/ram /opt/sybase/tempdb -t ext2 > /dev/null
       troll#>  /bin/chown sybase:sybase /opt/sybase/tempdb
       troll#>  /bin/touch /opt/sybase/tempdb/tempspace.dat
       troll#>  /bin/chown sybase:sybase /opt/sybase/tempdb/tempspace.dat
    Now we need to move tempdb from master to this new file. So we need to create a Sybase device, and then extend tempdb to this new device:
       1> disk init name="tempdbdev", physname="/opt/sybase/tempdb/tempspace.dat",
          vdevno=XX, size=26000
          (replace XX with the correct vdevno!)
       2> go
    Now to move tempdb off of master I suggest looking at the Sybase FAQ, Q1a.3

  • 3. Finally, modify the startup scripts (/etc/rc.d/sybase) to something like:
                /sbin/mke2fs -q -m0 /dev/ram 52000 -F > /dev/null
                echo "Mounting ramdisk to /opt/sybase/tempdb..."
                /bin/mount /dev/ram /opt/sybase/tempdb -t ext2 > /dev/null
                /bin/chown sybase:sybase /opt/sybase/tempdb
                echo "Touching Tempspace..."
                /bin/touch /opt/sybase/tempdb/tempspace.dat
                /bin/chown sybase:sybase /opt/sybase/tempdb/tempspace.dat
           case "$1" in
                echo "Initializing ramdisk..."
                /sbin/mke2fs -q -m0 /dev/ram 52000 -F > /dev/null
                echo "Mounting ramdisk to /opt/sybase/tempdb..."
                /bin/mount /dev/ram /opt/sybase/tempdb -t ext2 > /dev/null
                /bin/chown sybase:sybase /opt/sybase/tempdb
                echo "Touching Tempspace..."
                /bin/touch /opt/sybase/tempdb/tempspace.dat
                /bin/chown sybase:sybase /opt/sybase/tempdb/tempspace.dat
                echo "Shutting down Sybase ASE configured servers: "
                /sbin/killproc ${SYBASE}/bin/dataserver
                /sbin/killproc ${SYBASE}/bin/backupserver
                echo "Dismounting ramdisk /opt/sybase/tempdb"
                /bin/umount /opt/sybase/tempdb
    Note that modifying linux kernel files may invalidate your enterprise support contract with your Linux Support Vendor (e.g. Red Hat). Please contact your support vendor for approval prior to making any kernel source changes.

    It should also be noted that using tmpfs for a RAM disk is preferable to making a RAM drive. RAM drives require that the reserved space remain in physical memory. Memory usage must be carefully monitored to prevent memory starvation or excessive swapping of other processes. See Using a tmpfs device for tempdb for details.

• Maximum number of file descriptors

  • glibc-2.0.7-29 allows for a maximum of 1024 file descriptors (ASE 11.9.2 for Linux was built on this)
  • glibc-2.1.x allows for up to 16K file-descriptors
  • due to CR# 202238 we are limited to 256 file descriptors per engine. This was be fixed in

• Can I run more engines than CPUs?

  • The default behavior of ASE is to query /proc/cpuinfo for the number of CPUs
  • Set the SRV_CPUCOUNT environment variable to the number of engines to override this behavior
    $ setenv SRV_CPUCOUNT 8       <- up to 8 engines

• FreeBSD/other BSD derivatives

Wim ten Have has successfully started ASE 11.9.2 for Linux on FreeBSD 3.3 (taken from on October 7th, 1999)
I run the Linux/ASE 11.9.2 and Linux/OCS 11.1.1 on a FreeBSD setup FreeBSD 3.3-RELEASE #1 with Linux bin compatibility support enabled. It works.
       % uname -a
       FreeBSD 3.3-RELEASE FreeBSD 3.3-RELEASE #1: 
Thu Sep 30 19:32:09 CEST 1999
       % ps
         PID  TT  STAT      TIME    COMMAND
       10273  p0     Ss      0:00.10 -csh (csh)
       10294  p0     R+      0:00.00  ps
         266  v0-    S      35:47.04  dataserver -d./master.dat -sSYBASE
       % ipcs
       Message Queues:
       T     ID     KEY        MODE     OWNER    GROUP
       Shared Memory:
       T     ID     KEY        MODE     OWNER    GROUP
       m 196608 1761877794 --rw------- sybase    group
       T     ID     KEY        MODE     OWNER    GROUP

       % isql -Usa -P
       1> select @@version
       2> go

       Adaptive Server Enterprise/11.9.2/P/Linux Intel/Linux 2.2.5 i586/OPT/
Wed Aug 18 10:57:21 1999
*** Keep in mind that the distributed Adaptive Server Enterprise software for "Linux Intel" is and was never intended / tested, certified under such a setup. I run this parallel setup for curiosity, debug/test and educational purposes ;-) -- Wim ten Have.

• Client Library apps dump core on startup

On versions of linux that have glibc 2.1 (eg Red Hat 6.x) Client Library apps (including sybperl's Sybase::CTlib and DBD::Sybase) will dump core on startup if the context allocation routines fail. The context allocation routines load the locale information, using the SYBASE, LANG and LC_ALL environment variables to determine which locale information to load for date formatting and other data conversions.
The locales.dat file looks like this:
	locale = ENGLISH, us_english, iso_1
	locale = FRENCH, french, iso_1
	locale = GERMAN, german, iso_1
	locale = C, us_english, iso_1
	locale = default, us_english, iso_1
The SYBASE environment variable is used to find the locales.dat file (in $SYBASE/locales/locales.dat), and then the LANG or LC_ALL variables are used to find the correct locale entry in the locales.dat file. To do so it goes to the [linux] section of the file, and then looks for a line where the first token after the locale = part matches the LANG or LC_ALL variable.
By default RedHat 6.x (and possibly other distributions) set LC_ALL to a value that combines the country and the language. On my machine this is us_EN (for USA, English). This value is not in the locales.dat file, hence the problem.
On my system I've solved this by adding this value to the locales.dat file, like this:
*** locales.dat.orig	Tue Jan 18 17:48:32 2000
--- locales.dat	Thu Dec 23 10:14:39 1999
*** 166,171 ****
--- 166,172 ----
  	locale = default, us_english, iso_1
+ 	locale = en_US, us_english, iso_1
  	locale = ENGLISH, us_english, iso_1
  	locale = FRENCH, french, iso_1
  	locale = GERMAN, german, iso_1
If your Client Library app fails on startup you should therefore check the settings of these three environment variables, and make any adjustments that are needed.

• Can't connect to server from different host

You've installed Sybase on your linux machine, and you're certain that it's running. You can ping the host where Sybase is running from other hosts on your net, but you can't connect to the database server itself.

Chances are you are on a Red Hat 6.x system, where the standard installation creates an incorrect /etc/hosts file with the hostname as an alias on the localhost line, instead of on a line by itself. You can use netstat -a -n | grep <sybase port> (where sybase port is the port that Sybase is listening on) to verify that Sybase is listening to the correct IP address.

Check your /etc/hosts file - if it looks like this:	localhost    my_host
then you have a problem - change your /etc/hosts file to look like this instead:       localhost     my_host
(obviously you need to use the correct IP address for your host, and the correct host name!)

This should fix the problem.

An alternative solution is to change the hosts: entry in /etc/nsswitch.conf so that DNS or NIS is used before /etc/hosts for hostname lookups. By default /etc/nsswitch.conf has the following:

hosts: files nisplus dns
If you change that to something like
hosts: nisplus dns files
host name lookups should only access /etc/hosts if the information isn't available anywhere else, and therefore give the correct IP address for the hostname.

• Running ASE 12.5.x on RH 9

Added Aug 27 2003, thanks to Jason Froebe.

ASE 12.5.x fails to run on RH 9 because of a fix added to glibc. This fix causes the dynamic linker to revert to the i386 version of glibc in situations where the binary being run accesses _errno directly. The fix was done to ensure correct behavior for multi-threaded applications. Unfortunately ASE isn't compatible with this fix. A solution to this problem is provided below:

We now have a solution (courtesy of Jakub Jelinek from RedHat) rather than just a workaround:

From the Rawhide branch:

Note - as these files are no longer available from Red Hat I have made them available at

1) ASE needs to use /lib/i686/ to run properly. The RedHat patch makes us load /lib/ instead. On a default installation of AS 2.1, the library /lib/tls/ was not installed.

2) Only glibc < 2.3.2-31 should load /lib/ if the warning is printed.

3) Later glibc 2.3.2-31 and higher, will correctly load the /lib/i686/

Thanks to everyone that was involved to resolve this issue!

• Running ASE 12.5.1 on Fedora

Fedora is the new name of Red Hat's "consumer" releases (as opposed to their "Enterprise" releases).

ASE 12.5.1 requires a Java JVM to install. I downloaded mine from There are some instructions on performing the JVM install at

Next, the dataserver binary is linked with some older libraries. To get these libraries you need to install compat-libstdc++-7.3-2.96.118.i386.rpm. This is available in the Fedora distribution.

Now you are ready to go ahead and install.

Note that the 12.5.1 installer doesn't create a "sybase" user for you, doesn't install any rc files, and doesn't edit /etc/, so you'll have to do that yourself. Also remember to set the kernel.shmmax entry in /etc/sysctl.conf and run /sbin/sysctl -p before building a new server.

• Using a tmpfs device for tempdb

From a post to ase-linux-list by Jason Froebe.

There will be significant gains in performance if you create a tmpfs filesystem and put tempdb on it. tmpfs requires a recent 2.4 kernel such as 2.4.18 or so.

Create a directory called /dev/sybase_tempdb as the sybase user and change the permissons to 1700 as we only want Sybase to be able to write to it but we don't want it to be accidentally deleted. If you put the following entry in your /etc/fstab, it will create a 10GB tmpfs filesystem and mount it on /dev/sybase_tempdb.

tmpfs /dev/sybase_tempdb tmpfs mode=700,rw,size=10G 0 0
Note that, whatever size you choose, you have to have swap be AT LEAST 1x the size of all your tmpfs mounts.

You would then create your tempdb like so:

isql (shows 12.5.1 syntax):
1> disk init name = "tempdb2", physname ="/dev/sybase_tempdb/tempdb2.dat", 
vdevno = 8, size = "10G", dsync = false
2> go
1> alter database tempdb on tempdb2 = 10240
2> go
You would also have to modify your RUN_<server> file as any time you reboot your Linux box, you will have an empty tempdb directory.

touch /dev/sybase_tempdb/tempdb2.dat 
dataserver .....
According to Sybase TechSupport, Sybase Engineering has no objections to using tmpfs on Linux (it is used on the other unixes - not sure about Mac OSX though)

• Trace flag 1650 (Migrating passwords from Solaris to Linux)

Normally it isn't possible to migrate passwords (from master..syslogins) between platforms because the encryption is incompatible.

Trace flag 1650, available in 12.5.1, makes it possible for Solaris passwords to be copied to Linux servers and used there.

From CR #324847:

"Passwords from Solaris 32-bit/64-bit can be migrated to Linux using BCP or other data migration tools and used as such. Trace flag 1650 will turn on the compatibility mode. This compatibility mode is available only on Linux platform and only passwords from Solaris 32-bit/64-bit can be migrated."

• ASE 12.5.0.x and Async IO

ASE will use asynchronous IO by default. However, the async IO requests can sometimes block, causing "timeslice" errors to occur. This can be fixe by starting the server with the -T1639 traceflag. According to my information ASE 12.5.1 no longer requires this flag to be set.

• Can't allocate more than 128MB (ASE 11.x, RH EL 3.x)

When starting Sybase ASE 11.x under RedHat Enterprise Linux 3.x it is not possible to allocate more than 128MB of memory (sp_configure 'total memory'). This is due to a change in the format of /proc/self/maps which ASE uses to determine where to place the shared memory segment.

The fix consists in tricking ASE so that it doesn't see this file.
Mike Zakharoff contributed the following method:

        Here is how I did it using "vi -b" (binary edit), which worked
        great.  There are other binary editors available.
        # cd /opt/sybase/bin
        # cp -p dataserver dataserver.orig
        # vi -b dataserver
        search for the **FIRST** occurrence "/proc/self/maps", which
        looks like this on my system:
        /proc/self/maps^@NULL^@key: 0x%lx id: %d file:
        And change the "/proc" to something different... I used "/Proc"
        NOTE:  There is another "/proc/self/maps" entry, DON'T TOUCH
        that one!  Only change the one that is close to the
        "os_create_keyfile" entry, as above.
        I also changed the Sybase Boot information line to identify the
        hacked dataserver binary:
        Search for "P-FREE", which looks like this:
        SQL Server/ ESD#6/P-FREE/Linux Intel/Linux 2.2.14
        i686/1/DEBUG/Fri Mar 17 15:45:43 CET 2000
        I then changed "P-FREE" to "PATCH1", which fits byte for byte.

• Full-Text Search Engine can't communicate with ASE on Fedora Core 1 (12.5.x)

Fedora Core 1 has a kernel that enables the Native Posix Thread Library (NPTL). This is supposed to be 100% compatible with previous threading models, but it turns out that it triggers a bug in the Full Text search engine where a call to
fcntl(..., F_SETOWN)
fails due to a permission error.

The fix here is to ask the kernel to run this process in a different mode, using the LD_ASSUME_KERNEL environment variable:

[sybase@localhost install]$ LD_ASSUME_KERNEL=2.4.1 ./RUN_textsvr
Solution submitted by David Rees.

• Installing ASE 12.5.x fails on Fedora Core

In some circumstances ASE can fail to install with various "infected with 11" errors. These can be caused by Async IO errors, in which case the server must be started with traceflag 4061. As this can't be done in the RUN_xxx file during the install you have to use a little bit of trickery:
% setenv SYBASE <your-sybase-release-directory>
% setenv SYBASE_ASE ASE-12_5
% setenv SYBASE_OCS OCS-12_5
% set path = ($SYBASE/$SYBASE_ASE/bin $SYBASE/$SYBASE_OCS/bin $path)
% mv dataserver dataserver.bootstrap
% cat > dataserver
$SYBASE/$SYBASE_ASE/bin/dataserver.bootstrap $* -T4061
% chmod 755 $SYBASE/$SYBASE_ASE/bin/dataserver
% srvbuild
Once the server has been built you can undo the above operation and add the -T4061 traceflag to your RUN_xxx file.

Submitted by Wim ten Have (on the ase-linux-list mailing list)

• Installing/Running ASE on systems with glibc 2.4.x (Fedora Core 5, etc)

Note David Wein posted in sybase.public.ase.linux that this problem, which was followed by Sybase under CR 479363, is corrected in ASE 15.0.2 ESD4, and 15.0.1 Cluster Edition ESD 2. So with those versions you should not have to fiddle with LD_POINTER_GUARD anymore.
ASE (12.5.x, 15.x) will not run on a system with glibc 2.4.x (that's Fedora Core 5 and later, among others). Here is a work-around, supplied by "Chris" in sybase.public.ase.linux:

Symptoms of the problem are ASE's failing to build when you run the installer, or "Segmentation Fault" when trying to start an ASE instance. The Seg Fault happens right after Engine ) is brought online in the error log.
If you are running Fedora Core 5 or 6
You will need to set the environment variable LD_POINTER_GUARD to 0, in your sybase .profile, as follows:

Alternatively, just export this from the shell. If you haven't built any ASE's yet, you'll need to export this before running the installer, otherwise ASE will fail to build. If you are trying to boot an already installed ASE, then put it in your .profile / .bash_profile or export it as an environment variable before starting ASE.
If you are running Ubuntu / Kubuntu "Edgy"
You will need to set the environment variable LD_POINTER_GUARD to 1 in your sybase .profile, as follows:
I googled around a bit trying to find out what the LD_POINTER_GUARD thingie did and ran across a posting / blog where it talked about insome glibc versions it's backwards ... RedHat just made a change I guess and that's why you have to set it to "0" for Fedora and "1" for Ubuntu / Kubuntu / Debian (glibc 2.4). Same info applies if you are building a new ASE.
If you are running Suse 10.1 You will need to set the environment variable LD_POINTER_GUARD to 1 in your sybase .profile, as follows:
Same discussion as for Ubuntu.
I've tried all of the above they all work with the workaround listed. Happy ASE-ing! I've tested all of the above distros (sorry it took me so long, was on the road a lot over the last several weeks) and they allow ASE to boot; the workaround should be valid for ASE 15.x and 12.x (prolly even for 11.x if you wanted to try).

See also for more information.

• Some engines refuse to start

Patrick LeBoutillier supplied the following:

I stumbled onto a strange problem this week regarding ASE 12.5 on Linux (FC3, 2.6.17) where some of the engines where refusing to start with the following error message in the Sybase log:

00:00000:00010:2007/05/04 19:09:13.04 kernel upsetaffinity: can't affinity to engine 1 for kpid 851981 00:00000:00010:2007/05/04 19:09:13.04 kernel upsetaffinity: can't affinity to engine 1 for kpid 851981
After googling a bit, I found what appears to be the solution (depending on the kernel version):
in /etc/sysctl.conf, followed by a
$ sysctl -p

• srvbuild keyboard issue

Guy Gallagher posted the following to sybase.public.ase.linux:

When starting srvbuild, you may get the following errors:

Warning: translation table syntax error: Unknown keysym name: osfActivate
Warning: ... found while parsing ':osfActivate: ManagerParentActivate()'
cd to /usr/X11R6/lib/X11
create a symbolic link:
- ln -s /usr/share/X11/XKeysymDB XKeysymDB
cd to /usr/X11R6/lib/X11/locale
make symbolic links to
In my case, I had to create the directory /usr/X11R6/lib/X11/locale; YMMV.

• dsync performance with 2.6 kernels

ASE 15.0.2 (non-cluster edition) has very bad disk IO performance when using dsync on file-system devices on 2.6 kernels.

Ben Slade reports the following:

Surprisingly, on Linux 2.6, ASE 15.0.2's (non-cluster edition) performance on "dsync" devices (file or non-raw block based devices with the dsync option set) is horrible (about 8 times slower).

The really insidious thing here is if the master device is file based, you can't set the directio option. So you pretty much have to use raw devices for master. But the master device using dsync doesn't normally doesn't cause significant problems, except when you do stuff like dropping large databases or running installmaster. Then the server just takes forever to run the command.


As per "solved case" 11432104:

On a 2.6 linux kernel, with ASE 15.0.2 and higher you must use direct i/o on file system devices for good performance. In Cluster Edition, which is built on RHEL 4 (i.e. 2.6 kernel) we use direct i/o by default. But regular ASE 15.0.2 is built on RHEL 3, so it still uses dsync on by default. Regular ASE 15.0 will not be built on RHEL 4 until we merge the products.