Just today (after yesterday's upgrade, not long ago app-admin/logrotate was upgraded to 3.8.0) I've received the following mail from cron daemon: error: skipping "/var/log/portage/elog/summary.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation. Permissions to /var/log/portage/elog/ are drwxrws--- 2 portage portage 240 Авг 15 09:48 elog/ /etc/logrotate.d/elog-save-summary contents is: # Copyright 1999-2007 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # Rotate the log created by the save_summary elog module. /var/log/portage/elog/summary.log { missingok nocreate delaycompress } According to quoted message it seems to ask for update to: # Copyright 1999-2007 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # Rotate the log created by the save_summary elog module. /var/log/portage/elog/summary.log { ++ su portage portage missingok nocreate delaycompress } Also: rotation config file (in my case, rather old installation) is named /etc/logrotate.d/elog-save-summary To my ming the name elog-summary will look much better.
After adding suggested patch to /etc/logrotate.d/elog-save-summary warning disappeader, the logfile was rotated successfully.
(In reply to comment #1) > After adding suggested patch to /etc/logrotate.d/elog-save-summary warning > disappeader, the logfile was rotated successfully. But it was not enough: Today I've received the mail with new error message: error: error setting owner of /var/log/portage/elog/summary.log-20110815.gz: Operation not permitted
Just ran into this myself, exact same issue. /etc/logrotate.d/elog-save-summary belongs to sys-apps/portage, I don't think this is a logrotate bug, portage just needs to update the conf file it drops in. Hmm, although the new config probably won't work with the old logrotate, so logistically it's unclear the best way to go to get the right config installed. Portage installs a config based on what version of logrotate is installed, and logrotate generates a ewarn to reinstall portage when installed?
I think this is fixed in portage 2.1.10.11, see bug 378451
(In reply to comment #4) > I think this is fixed in portage 2.1.10.11, see bug 378451 Thank you. Yes it is. In addition I had to chown portage the existing summary.log files and want to wait for a time to check. If success --- the bug is entirely RESOLVED FIXED.
Fixed in portage 2.1.10.11.
It seems to me that this fix was not really correct. For me logrotate cannot rotate the file anymore due to permission denied: ~ # /usr/sbin/logrotate -d /etc/logrotate.conf 2>&1|grep summary.log rotating pattern: /var/log/portage/elog/summary.log weekly (4 rotations) considering log /var/log/portage/elog/summary.log error: stat of /var/log/portage/elog/summary.log failed: Permission denied ~ # If I change "su portage portage" to "su root portage" in /etc/logrotate.d/elog-save-summary it works fine. This is a system with hardened profile, perms look like this: ~ # ls -lad /var drwxr-xr-x 14 root root 4096 Jul 7 20:34 /var ~ # ls -lad /var/log drwx-----x 7 root root 20480 Oct 4 03:11 /var/log ~ # ls -lad /var/log/portage/ drwx-wS--- 3 portage portage 4096 Sep 3 2009 /var/log/portage/ ~ # ls -lad /var/log/portage/elog/ drwxrws--- 2 portage portage 36864 Oct 4 22:46 /var/log/portage/elog/ ~ # ls -la /var/log/portage/elog/summary.log -rw-r--r-- 1 root portage 0 Oct 1 10:31 /var/log/portage/elog/summary.log ~ # To be honest, I do not know why logrotate gets a permission denied. To me the permissions look like user portage should be able to stat the file. Testing with a shell using "su -s /bin/bash - portage" does not get a permission denied. -Marc
The directory also needs write permission to portage, or the old file cannot be moved to the new name.
I still suffer this problem: $ emerge --info portage logrotate Portage 2.1.11.31 (default/linux/amd64/10.0/desktop/gnome, gcc-4.6.3, glibc-2.15-r3, 3.6.11-gentoo x86_64) ================================================================= System Settings ================================================================= System uname: Linux-3.6.11-gentoo-x86_64-Intel-R-_Pentium-R-_Dual_CPU_T2330_@_1.60GHz-with-gentoo-2.1 Timestamp of tree: Sun, 03 Feb 2013 00:45:01 +0000 ld GNU ld (GNU Binutils) 2.22 app-shells/bash: 4.2_p37 dev-java/java-config: 2.1.12-r1 dev-lang/python: 2.7.3-r2, 3.2.3 dev-util/cmake: 2.8.9 dev-util/pkgconfig: 0.27.1 sys-apps/baselayout: 2.1-r1 sys-apps/openrc: 0.11.8 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.11.6 sys-devel/binutils: 2.22-r1 sys-devel/gcc: 4.6.3 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.6 (virtual/os-headers) sys-libs/glibc: 2.15-r3 Repositories: gentoo ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -march=native" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="${EPREFIX}/etc/gconf /etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -pipe -march=native" DISTDIR="/usr/distfiles" EMERGE_DEFAULT_OPTS="--jobs=3 --keep-going --autounmask-write" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://mirror.ovh.net/gentoo-distfiles" LANG="es_ES.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j3" PKGDIR="/usr/local/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="32bit X a52 aac acl acpi alsa amd64 berkdb branding bzip2 cairo cdda cddb cdr cli colord consolekit cracklib crypt cups cxx dbus dhcpcd djvu dri dts dvd dvdr eds emboss encode evo exif fam fat ffmpeg firefox flac fortran gdbm gif gnome gnome-keyring gnome-online-accounts gpm gstreamer gtk gtk3 gtkstyle iconv jpeg lcms ldap libnotify mad mmx mng modules mp3 mp4 mpeg mudflap multilib nautilus ncurses network-cron networkmanager nls nptl nsplugin ogg opengl openmp pam pango pch pdf png policykit ppds pulseaudio qt3support readline scanner sdl session socialweb spell sse sse2 ssl startup-notification svg tcpd theora tiff truetype udev udisks unicode upower usb v4l vdpau vorbis wxwidgets x264 xcb xml xv xvid zlib" ABI_X86="64" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="evdev synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="es es_ES" PHP_TARGETS="php5-3" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2" RUBY_TARGETS="ruby18 ruby19" USERLAND="GNU" VIDEO_CARDS="vesa intel" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON ================================================================= Package Settings ================================================================= sys-apps/portage-2.1.11.31 was built with the following: USE="(ipc) (multilib) -build -doc -epydoc (-pypy2_0) -python2 -python3 (-selinux) -xattr" LINGUAS="-pl" app-admin/logrotate-3.8.3 was built with the following: USE="acl (multilib) (-selinux)"
/etc/logrotate.d/elog-save-summary is provided by portage, not sure if it's ok
Maybe this helps: chown portage:portage /var/log/portage chmod g+ws /var/log/portage The portage ebuild does this automatically when upgrading from <sys-apps/portage-2.1.10.11', but maybe you permissions got messed up somehow.
Will try when I come back to affected system, thanks. Wouldn't be safer to run: if [[ -d ${ROOT}var/log/portage && \ $(ls -ld "${ROOT}var/log/portage") != *" portage portage "* ]] && \ has_version '<sys-apps/portage-2.1.10.11' ; then # Initialize permissions for bug #378451 and bug #377177, since older # portage does not create /var/log/portage with the desired default # permissions. einfo "Applying portage group permission to ${ROOT}var/log/portage for bug #378451" chown portage:portage "${ROOT}var/log/portage" chmod g+ws "${ROOT}var/log/portage" fi for all updates? (not only for <sys-apps/portage-2.1.10.11) If permissions are wrong, they need to be fixed (no matter how the got changed)
(In reply to comment #12) > for all updates? (not only for <sys-apps/portage-2.1.10.11) If permissions > are wrong, they need to be fixed (no matter how the got changed) I think changing them for every update would be too aggressive, since that would preclude users from making local adjustments. Besides, it shouldn't be necessary to do it for every update.
(In reply to comment #11) > Maybe this helps: > > chown portage:portage /var/log/portage > chmod g+ws /var/log/portage > > The portage ebuild does this automatically when upgrading from > <sys-apps/portage-2.1.10.11', but maybe you permissions got messed up > somehow. Yes, it helps. In my case while working under this issue were performed following changes: 1. # ls -l /var/log/ | grep portage ... drwxrws--- 3 portage portage 72 мая 24 2012 portage/ ... # cat /etc/logrotate.d/elog-save-summary # Copyright 1999-2011 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # Rotate the log created by the save_summary elog module. /var/log/portage/elog/summary.log { su portage portage missingok nocreate delaycompress } With sys-apps/portage-2.1.11.50 log rotation works fine. Forceing file mode on each update is not a good idea. But performeing a check, with echoing warning (need to set correct mode for directory) looks well enough.
(In reply to comment #14) > Forceing file mode on each update is not a good idea. > But performeing a check, with echoing warning (need to set correct mode for > directory) looks well enough. An einfo message for every update? I guess that would be reasonable, since einfo is not logged by default.
(In reply to comment #15) > (In reply to comment #14) > > Forceing file mode on each update is not a good idea. > > But performeing a check, with echoing warning (need to set correct mode for > > directory) looks well enough. > > An einfo message for every update? I guess that would be reasonable, since > einfo is not logged by default. elog looks to be better. Not every update, but each re-emerge, when mode check fails (shows incorrect permissions).
(In reply to comment #16) > (In reply to comment #15) > > (In reply to comment #14) > > > Forceing file mode on each update is not a good idea. > > > But performeing a check, with echoing warning (need to set correct mode for > > > directory) looks well enough. > > > > An einfo message for every update? I guess that would be reasonable, since > > einfo is not logged by default. > > elog looks to be better. > Not every update, but each re-emerge, when mode check fails (shows incorrect > permissions). So, if they don't want the default permissions, they'll have to see an elog message about this for every update? That doesn't seem very friendly. I guess we could write a hidden file at /var/log/portage/.permissions_warning_shown, and skip the warning if the file exists.
Or allow to set a variable in make.conf to skip elog message like can be done currently with games elog messages... Anyway, probably most people will update portage just after emerge --sync running "emerge portage" and, then, they will see einfo message as well :/
With the default PORTAGE_ELOG_CLASSES="log warn error" setting, einfo messages aren't logged, so you only see them if you are looking at the ebuild output for some reason. People who use --jobs, --quiet-build, or --quiet only see the build output if they read the log file.
(In reply to comment #17) > So, if they don't want the default permissions, they'll have to see an elog > message about this for every update? First of all we are to answer on question about conditions of correct operability (i.e. summary log rotation) in non-default configuration (particularly with non-default permissions). Fow my particular experience, usage of non-default configuration usually is followed with _silent_ (!) issues (was a time, when I've tryed to use completely syslog journalling). To my mind this silentness is exactly not friendly behabiour. BTW, is portage syslog logging facility operable for now?
(In reply to comment #20) > BTW, is portage syslog logging facility operable for now? It's supposed to work, if you put a setting like this in make.conf: PORTAGE_ELOG_SYSTEM="${PORTAGE_ELOG_SYSTEM} syslog" It worked the last time that I tested it.
(In reply to comment #20) > Fow my particular experience, usage of non-default configuration usually is > followed with _silent_ (!) issues Doesn't logrotate already make noise if /var/log/portage has the wrong permissions?
(In reply to comment #22) > (In reply to comment #20) > > Fow my particular experience, usage of non-default configuration usually is > > followed with _silent_ (!) issues > > Doesn't logrotate already make noise if /var/log/portage has the wrong > permissions? yes, that is the reason for my noticing the problem on my uncle's laptop: he was getting mails from cron jobs failing to run logrotate for summary.log
(In reply to comment #23) > yes, that is the reason for my noticing the problem on my uncle's laptop: he > was getting mails from cron jobs failing to run logrotate for summary.log Do you have any idea how his permissions got messed up?
No, I reset them some weeks ago, lets see if they break again :/
(In reply to comment #22) > Doesn't logrotate already make noise if /var/log/portage has the wrong > permissions? Just standard cron mails. To my mind it's not enough, first of all it should write error messages to a log (by default messages). But it is an upstream issue.
