fdb_

Have you tried ccache ?

Hi, Am I the only one wanted to browse over the forums using https ? If yes this is too bad Anyway, it seems that when you direct access to the forum with https it works fine except that any links are written with http, so you left the secure browsing as soon as you click a link.... TheLuda can you check this ? Kind regards, fdb.

hehe you right

Maybe moving it to unit to also handle vehicles power types in future ?

.rename DasBlub Undertaker

I fully agree with DasBlub. But I am affraid to use a poor (even if it is practical) bugtracker. In my mind a bugtracker will ease a lot of work but many of public facilities giving access to a bugtracker does not implement workflows, categorization or a good search engine... The lack of those features can be a pain to comunicate, exchange and find the right information for most of people. My 2 cents.

Seems that some semaphore can become residual almost like zombie processes (I cannot confirm btw). Yeah you are right I write this and it is totally wrong In fact all these params are in one kernel config named "kernel.sem". List current semaphore values: # ipcs -ls ------ Semaphore Limits -------- max number of arrays = 128 max semaphores per array = 250 max semaphores system wide = 32000 max ops per semop call = 32 semaphore max value = 32767 You can also use the following command: # cat /proc/sys/kernel/sem 250 32000 32 128 Here are the information I found from the Oracle recommendations (should work for any other hungry systems): Dynamic setting: # echo "250 32000 100 128" > /proc/sys/kernel/sem Persistant settings: # echo "kernel.sem=250 32000 100 128" >> /etc/sysctl.conf I hope this one will work

I think this is related to mangos and not to system. When I spoke about Oracle I did not mean that it came from the SQL server. But I was refering to some Linux system requirements for a medium loaded Oracle on Linux (some system tuning - including semaphores - have to be set). In some case mangos can be very greedy. So some system tuning can be mandatory. BTW, I think you set the number of allowable semaphores far too high, something like 1K seems already very high to me and should be fine for most of the mangos servers.

I also have those error on a test server but I did not think it was a problem. I will try to find a workaround but I cannot promise to do it quick. Meanwhile you can try to put these lines in your sysctl config file (in fact, that are the tests I will do on my test server): kernel.semmsl = original value * 4 (or * 8) kernel.semmns = original value * 4 (or * 8) kernel.semopm = original value * 4 (or * 8) kernel.semmni = original value * 4 (or * 8) Of course, still use sysctl -a to find the current system values. NB: The sysctl config file need to be reloaded to apply the changes (or reboot your server). Also, I have heard from a Veritas engineer that some kind of semaphores can only be cleaned with a system reboot (I doubt that this is the only solution but it worth a try to have a clean system before reproducing the error). You can try to list the semaphores with ipcs -a And to delete semaphore ipcrm -s [i]id[/i] Be gentle because some semaphores does not belong to mangos but to other system processes. Good luck.

Try this: echo 134217728 >/proc/sys/kernel/shmall echo 134217728 >/proc/sys/kernel/shmmax Or put in your sysctl config file (to have the settings kept after a reboot): kernel.shmall = 134217728 kernel.shmmax = 134217728 There are the descriptions of the semaphore kernel params: SEMMSL: maximum number of semaphores per id SEMMNS: maximum number of semaphores, system wide. SEMOPM: maximum number of operations in one semop call. SEMMNI: number of semaphore identifiers (or arrays), system wide. You can also tune the semaphore max numbers to avoid these messages. For example Oracle needs value larger than 100 in semaphore kernel params. To list all the system params: sysctl -a (use grep to find the one you want) Also try to use google to find system kernel config for Oracle, perhaps it will help. Good luck and keep us updated.

BEware of the white rabbit !!! This one is awesome

I think it was good to mention the copyrights issue and al that's around it but now I think that focusing on the main thread subject will be more constructive. Please good forward guys, this is not a forum where it is good to flame

Yes something like that will permit to handle special cases and also to automate the updates.

Nice patch

Yes that's true, for example sometimes the databse name is hardly coded in the script, if you have changed the default db names you can run in deep trauma...

The following is a try to revamp the old ticket engine in a new fashion manner. It is deeply inspired by laise and Janu work. Let's go with some specs: In game commands: Deleting tickets: .ticket del all $Char_name (Delete all the tickets created by $Char_name) .ticket del all (Delete all the tickets in the database !!!) .ticket del all opened (Delete all open tickets) .ticket del all closed (Delete all closed tickets) .ticket del $Ticket_id (Delete ticket $Ticket_id) .ticket del before $date (Delete tickets before the given date...) Used to clean the ticket from database. Delete a ticket (or many tickets) without checking their status, neither if they are assigned. Deleting tickets commands should be configured as level 3. Special behaviour: When the GM select a player, .ticket del all will delete all the tickets opened by this player (including opened/closed/pending tickets) Closing tickets: .ticket close all $Char_name (Close all the tickets opened by $Char_name) .ticket close all (Close all the tickets opened) .ticket close $Ticket_id (Close the ticket $Ticket_id) .ticket close $Ticket_id $Reason (Close the ticket $Ticket_id with $Reason) Closing a ticket (or many tickets) will flag the ticket as closed, without deleting it from the database. A GM can only close the tickets that are assigned to him or assigned to GM's with lower access rights. Only assigned tickets can be closed. Example: GM_lvl3 can close all the tickets opened by the player JDoe (command: ".ticket close all JDoe") even if the tickets are handled by different GM (GM_lvl1_A and GM_lvl1_B ), but GM_lvl1_A using the same command (".ticket close all JDoe") will result in only closing the tickets he is handling. Same behavior applies to every commands. Assigning tickets: .ticket assign (Assign the current tickets of the selected player to the GM who is writing this command) .ticket assign $Ticket_id (Assign the $Ticket_id to the GM who is writing the command) .ticket assign $Ticket_id $GM_Name (Assign the $Ticket_id to $GM_Name) .ticket assign level $Ticket_Id $level (Set the ticket to be handled by a $level GM) .ticket assign level $Ticket_Id $level $Reason (Set the ticket to be handled by a $level GM with $Reason) A GM assigns the tickets with those commands. A GM can assign a ticket to himself or to lower level GM only. Requeing tickets: .ticket requeue $Ticket_id (Requeue the ticket $Ticket_id) .ticket requeue $Ticket_id $Reason (Requeue the ticket $Ticket_id with $Reason) Tickets history: .ticket history $Ticket_id (Show the ticket history) Basically unassign the ticket. Additional information: - Every command should check the GM level to avoid assiging/closing/requeuing/deleting tickets that are handled by higher level GM's. - $Reason field can be handled as an history field, text format can be discussed later (something like :timestamp: text msg\\n\\r:timestamp: msg2....). Update of this field occurs: -- when an escalation is requested, -- when a requeue is requested, -- when the ticket is closed. - The use of SOAP can help to handle almost all the ticketing system from an external adm website. This is a pretty complete ticket system. Development start: on-hold. Due date: to be defined. If this project has a dev planned I will make a dedicated thread. Any comments are welcome.

Keeping the number of cleared ticket per GM seems also a good idea.

Current ticket handling is very basic, so this modification is very very useful.

Tested on [10392] and does not disappear.

Certainly moving hosting to http://kpsn.net/

It seems interesting to have this kind of patch. With the lastest RPS and RFS linux kernel patches (included in mainstream from the last kernel 2.6.35) it can be a very efficient way to handle massive amount of clients. More information: - Receive Packet Steering (RPS) http://lwn.net/Articles/328339/ - Receive Flow Steering (RFS) http://lwn.net/Articles/382428/

Hehe, that's right I just forgot "or fully..."

Another way to improve mysql seems to use thread cached mallocs developped by google. Install and add "LD_PRELOAD="/usr/lib/libtcmalloc.so"" in your mysqld_safe (or fully recompile mysql with this new malloc). http://google-perftools.googlecode.com/svn/trunk/doc/tcmalloc.html

Hi DaViper, I fully agree with you for the convenient purpose of combining patch Managing an high amout of diff file and handling conflicts is a 24/7 work without a good planning. But on the dev side I prefer to see atomic commits on my own repository (even on outside repo's).

I do not have a crash using YTDB. Peerhaps it is related only to a DB issue, in that case report the problem on the DB forums.