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

[LDM #WBL-938424]: LDM Logging



Adam,

> Yup....that's the problem.
> 
> Syslog does not have permissions to write to the file.  If I change the file
> permissions to everyone can write...it starts to work.  But when I restart
> the LDM, it changes the modified ldmd.log to ldmd.log.1 and then creates a
> new ldmd.log but without the write flag for everyone....then back to 0 size.
> I'm not sure how to give syslog "permanent" write permissions considering
> the LDM keeps setting them back every restart.  I tired making syslog a
> member of the ldm group....but still nothing in the ldmd.log file.

As long as the system logging process isn't owned by "root", then your only 
option is to always have the LDM log file be writable by everyone, which would 
require having the umask of the LDM user be 0, which is not a good idea.

The solution, then, is to figure-out how to have "root" be the owner of the 
system logging process. How is it started?

> Hupsyslog gives me this in the syslog log file when run:
> 
> Jun 26 16:19:14 tornado rsyslogd: [origin software="rsyslogd"
> swVersion="5.8.6" x-pid="1713" x-info="http://www.rsyslog.com";] rsyslogd was
> HUPed
> 
> It doesn't give me a exit status that I know of...just back to the prompt.

The exit-status of a process is stored in the shell-variable "$?" for a 
standard shell (e.g., bash(1)) and in "$status" for csh(1)-like shells.

> Thanks,
> 
> Adam

Regards,
Steve Emmerson

Ticket Details
===================
Ticket ID: WBL-938424
Department: Support LDM
Priority: Normal
Status: Closed


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.