Bug 887340
| Summary: | Rectify suboptimal logrotate arrangement imposing server restarts | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Jan Pokorný [poki] <jpokorny> |
| Component: | luci | Assignee: | Jan Pokorný [poki] <jpokorny> |
| Status: | CLOSED ERRATA | QA Contact: | cluster-qe <cluster-qe> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.4 | CC: | cfeist, cluster-maint, fdinitto, rmccabe, rsteiger, slevine, tlavigne |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | luci-0.26.0-91.el6 | Doc Type: | Bug Fix |
| Doc Text: |
Cause:
Logrotate configuration for luci imposed restarting this web
application so as to make it start logging to the new file
(old one has just been rotated).
Consequence:
This interferes with the assumption luci will run without
interruptions so that it can provide a smooth experience
without intermittent issues or delays.
Fix:
Luci is now able to adapt to rotated file automatically,
hence the directive imposing restart could have been
removed from its logrotate configuration. Note, however,
that if you are updating from a RHEL 6.8 version of luci or
older, you need to drop the automatic RPM extension from
/etc/logrotate.d/luci.rpmnew (or remove said directive
on your own) to experience the new, desired behavior.
Result:
Luci now works smoothly even at the time of logrotate
routine crossing its path.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-03-21 11:38:23 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Jan Pokorný [poki]
2012-12-14 17:30:55 UTC
Actually, using "copytruncate" option in the logrotate config file might be a better solution. Reminder for possible heads up in release notes: When the user performes update of luci to version in "Fixed in version" field or higher, hence when updating manually can observe > warning: /etc/logrotate.d/luci created as /etc/logrotate.d/luci.rpmnew if some changes were made to /etc/logrotate.d/luci, she is suggested to drop > postrotate > /sbin/service luci condrestart 2>/dev/null >/dev/null || : > endscript from that file (or just "cp /etc/logrotate.d/luci{.rpmnew,}") to avoid now spurious/unneeded restarts of luci when rotating the logs kicks in. (This because the file is marked %config(noreplace).) I missed the "corner case" of initial luci setup:
# paster setup-app /var/lib/luci/etc/luci.ini --no-default-sysconfig
> Traceback (most recent call last):
> File "/usr/bin/paster", line 9, in <module>
> load_entry_point('PasteScript==1.7.3', 'console_scripts', 'paster')()
> File "/usr/lib/python2.6/site-packages/paste/script/command.py", line 84, in run
> invoke(command, command_name, options, args[1:])
> File "/usr/lib/python2.6/site-packages/paste/script/command.py", line 123, in invoke
> exit_code = runner.run(args)
> File "/usr/lib/python2.6/site-packages/paste/script/appinstall.py", line 68, in run
> return super(AbstractInstallCommand, self).run(new_args)
> File "/usr/lib/python2.6/site-packages/paste/script/command.py", line 218, in run
> result = self.command()
> File "/usr/lib/python2.6/site-packages/paste/script/appinstall.py", line 446, in command
> self.logging_file_config(config_file)
> File "/usr/lib/python2.6/site-packages/paste/script/command.py", line 757, in logging_file_config
> fileConfig(config_file)
> File "/usr/lib64/python2.6/logging/config.py", line 84, in fileConfig
> handlers = _install_handlers(cp, formatters)
> File "/usr/lib64/python2.6/logging/config.py", line 161, in _install_handlers
> args = eval(args, vars(logging))
> File "<string>", line 1, in <module>
> AttributeError: 'file' object has no attribute 'filename'
There was yet another issue found with the new changes: The problem occurs when you install luci anew and set LOG_FILE to a nondefault value, the proceed with "service luci start". Some early setup tasks (not triggered upon subsequently start of luci) have to -- by design -- resort to using default log file, but then it's not precreated with correct owner (root instead) so it subsequently fails on inability to write to that file. This is now fixed and both custom + default log files are initially pre-created with desired owner so this failure can no longer happen. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2017-0766.html |