The error message means that one (or more) of the shared libraries required for TCP communications to work could not be loaded, perhaps due to o/s package updates? or it can mean that the /tmp/.oracle directory is not writeable by the oracle user (or doesn't exist perhaps because someone did some 'housekeeping' on /tmp . In either case tracing the listener at level 16 as Gaius suggested should reveal the issue.
Oracle has an alert log which should tell you when and why it shut down. Depending on how the database was configured, that will be under a directory identified by either the diagnostic_dest or background_dump_dest parameters, and will be called alert.xml or alert.log (in previous versions). If you're running it, you can get information from Enterprise Manager too.
Has the server it's running on rebooted as well? If so the listener may be configured to start automatically, but the database not; there's a flag in the oratab file that says whether each instance should start, e.g. when dbstart is run, which could be done from an init.d script on boot. You could try changing the flag for your database from N to Y to see if it stops you having to start it manually, at least.
If the server hasn't rebooted then the database may have crashed, in which case I'd expect to see errors in the alert log - search backwards, particularly for ORA-00600 errors which can be fatal, but also for anything close to the time it crashed.
Based on the ORA-600 in the alert log, this looks like it might be bug 6651027, which is related to the resource manager and is supposedly fixed in 11.1.0.7 and 11.2. If you have access to the Oracle Support website you could look at note 559251.1, and the patch set notes. You can also look at the trace file referenced in the alert log for more detail on exactly where it's failing.
If you're on an earlier release I'd recommend you patch up and see if the problem goes away. If it doesn't then you'll need to raise a support assistance request with Oracle I'm afraid. ORA-600s that aren't already fixed in a patch sometimes have a workaround, but often need Oracle's input.
Best Answer
You can change the default retention policy of oracle log and trace files.
Source: https://streetkiter.wordpress.com/2011/04/06/do-you-really-need-one-year-old-logs-and-traces-for-your-oracle-database/
Relevant extract:
There are two parameters: SHORTP_POLICY (default 720 hours) and LONGP_POLICY (default 8720 hours). so SHORTP_POLICY is 30 days while LONGP_POLICY is 365 days.
From the commandline run "adrci". In adrci, use the following commands.
And now the traces are dropped after one week (SHORTP) or one month (LONGP).