[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20050901: [SSEC-TC-req #10653] syslogd on amrc.ssec.wisc.edu



>From: Matthew Lazzara <address@hidden>
>Organization: SSEC/AMRC
>Keywords: 200509011411.j81EB6jo005065 LDM

Matthew, Scott, et. al.,

re:
>Support at Unidata (Tom, Steve, et al).  Please read below what I did  
>poorly, and how things still aren't right. As a note to you, have to  
>run LDM version 6.3.0, since the my attempts to installed a newer  
>version 6.4.1 failed (I'm sure due to the combination of SunOS,  
>compiler, etc.).  Please let me know if you need to see any of my log  
>files or if you have any questions.

Immediately I see a reference to 'killall' which I assume is a
reference to the LDM utility 'hupsyslog'.  There are a number of
issues here:

- killall should be run from hupsyslog _only_ on SGI systems; all
  others support direct use of 'kill' to send a signal to a process

- if your Solaris installation is trying to use 'killall' it means
  that you had some environment variables set that you shouldn't have
  before you ran the 'configure' script that creates the LDM make files.
  You should _not_ have the following environment variables defined
  before running 'configure':

  CC
  CFLAGS
  CPPFLAGS
  LDFLAGS
  LIBS

On SGI, 'killall' is used to send a signal to a process using its
name.  'hupsyslog' uses 'kill' to send a HUP signal to syslogd
so that syslogd will close the open file descriptor to the LDM log
file so that the log file can be 'rotated' (renamed and a new one
created in its place).

re:
  "If this is an LDM bug, it's a bad bug.  Because if 'killall' did work
   for you, it would have all but turned amrc off."

This is not an LDM bug, it is a user error the solution for which is
get one's environment setup correctly before attempting an LDM build.

So, what you need to do is the following:

<logon as 'ldm'>

ldmadmin stop             <- stop the LDM if it is running

-- examine your enviornment to see what environment variables you have
   defined:

env

-- unset all environment variables that would be used by 'configure'

cd ldm-6.3.0/src
make distclean
./configure
make
make install

su
make install_setuids
exit

That should be it.

If you need help figuring out what to undefine, please send me the
output of 'env'.

Cheers,

Tom

>On Sep 1, 2005, at 8:59 AM, Scott Nolin via RT wrote:
>>
>> Matt,
>>
>> The problem is the "killall" on solaris (8 and 9 at least, dunno about
>> 10) is used to kill ALL ACTIVE process not related to the shutdown
>> procedure.  On linux you can use it to kill all processes with a  
>> certain
>> name.
>>
>> If this is an LDM bug, it's a bad bug.  Because if 'killall' did work
>> for you, it would have all but turned amrc off.
>>
>> If the script instead ran "/etc/init.d/syslog restart" it would do  
>> what
>> they want.
>>
>> I looked at it a little, and I think all they are trying to do is  
>> rotate
>> their logs and restart the syslogger.
>>
>> If unidata doesn't have a fix, we could perhaps cron something up as
>> root to get the same job done.
>>
>> Scott
>>
>> Matthew Lazzara via RT wrote:
>>
>>>
>>>
>>> Thu Sep  1 08:08:21 2005: Request 10653 was acted upon.
>>> Transaction: Ticket created by address@hidden
>>>        Queue: unix.admin
>>>      Subject: syslogd on amrc.ssec.wisc.edu
>>>        Owner: Nobody
>>>   Requestors: address@hidden
>>>       Status: new
>>>  Ticket <URL: https://rt.ssec.wisc.edu/Ticket/Display.html?id=10653 >
>>> --------------------------------------------------------------------- 
>>> ----
>>>
>>>
>>> Hello!
>>>
>>> I have a question for you that you may or may not be able to help
>>> with.  As you may know, we run Unidata's LDM software.  I recently
>>> installed a version of it (6.3.0), and before attempting to use it, I
>>> failed to su as root (rmattl), and run a short script to setuid a few
>>> programs as a part of the However, despite this, I'm getting errors
>>> like the one below - complaining that the program hupsyslog isn't
>>> setuid, but it really is (check it out on amrc.ssec.wisc.edu in ~ldm/
>>> bin).  So, I wonder if the command killall that it has tried to run
>>> would work, and it doesn't.  Is there something that you can think of
>>> incorrect here at all?  I can't even find a syslogd on
>>> amrc.ssec.wisc.edu - should there be? could there be? Is there
>>> something different for Sun Solaris?
>>>
>>> If this doesn't make sense to you folks at all, I will next ask
>>> Unidata support for help..but I thought I'd check with you folks
>>> first to see if there was anything you could think of that doesn't
>>> make sense.
>>>
>>> Thanks in advance for your help!
>>>
>>> Best Regards,
>>>
>>> Matthew
>>>
>>>
>>> Begin forwarded message:
>>>
>>>
>>>
>>>> From: Unidata LDM software <address@hidden>
>>>> Date: September 1, 2005 12:00:04 AM CDT
>>>> To: address@hidden
>>>> Subject: Output from "cron" command
>>>>
>>>>
>>>> Your "cron" job on amrc
>>>> /home2/ldm/bin/ldmadmin newlog
>>>>
>>>> produced the following output:
>>>>
>>>> usage: killall [signal]
>>>> hupsyslog: system("/etc/killall -HUP syslogd") returns 256
>>>> (E.G. It didn't work. Check that this program is setuid)
>>>>
>>>>
>>>>
>>>
>>>
>>> --------------------------------------------------------------------- 
>>> ---
>>> ---
>>> Matthew Lazzara - Meteorologist - Anarctic Meteorology Research  
>>> Center
>>> Space Science and Engineering Center            E-mail:
>>> address@hidden
>>> University of Wisconsin-Madison                 Phone: (608) 262-0436
>>> 1225 West Dayton Street, Madison, WI 53706      Fax: (608) 263-6738
>>> --------------------------------------------------------------------- 

--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publicly available
through the web.  If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.