Content logged to /var/log/upstart

Bug #1318535 reported by Removed by request
6
Affects Status Importance Assigned to Milestone
alsa-utils (Ubuntu)
New
Undecided
Unassigned
console-setup (Ubuntu)
New
Undecided
Unassigned
cryptsetup (Ubuntu)
New
Undecided
Unassigned
mountall (Ubuntu)
Opinion
Undecided
Unassigned
procps (Ubuntu)
New
Undecided
Unassigned
upstart (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

I'm using Ubuntu 14.10 dev and I'm noticing things logged to /var/log/upstart which may not be intended in this way. After deleting all logs and making a reboot I'm getting these things:

alsa-state.log with "alsa-state stop/pre-start, process 1063" and container-detect.log with "container-detect stop/pre-start, process 278".

I'm not sure why a stop/pre-start event is logged as it is very common and doesn't provide very useful information.

console-setup.log with "Loading /etc/console-setup/cached.kmap.gz".

Maybe this could be intended but I'm not so sure about this too.

cryptdisks.log with " ...done.".

This log is incomplete and it looks the missing part is in /var/log/boot.log with " * cryptswap1 (starting).." and " * cryptswap1 (started)...  * Starting early crypto disks...  ". Maybe all content of /var/log/upstart/cryptdisks.log should go into /var/log/boot.log.

mountall.log with "fsck von util-linux 2.20.1
/dev/sda1: sauber, 205747/9199616 Dateien, 16090003/36781311 Blöcke".

This looks more useful but I'm wondering if this shouldn't go better into /var/log/boot.log too.

procps-static-network-up.log and procps-virtual-filesystems.log with "kernel.printk = 4 4 1 7
net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2
kernel.kptr_restrict = 1
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
kernel.sysrq = 176
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.tcp_syncookies = 1
kernel.yama.ptrace_scope = 1
vm.mmap_min_addr = 65536
kernel.pid_max = 4194303
vm.dirty_background_bytes = 16777216
vm.dirty_bytes = 16777216
vm.dirty_expire_centisecs = 0
vm.dirty_writeback_centisecs = 0
vm.laptop_mode = 1
vm.swappiness = 0
net.ipv4.ip_default_ttl = 255
net.ipv4.tcp_low_latency = 1"

It looks not intended that the same sysctl options are logged in 2 different files. Maybe it is even not intended to create any of these both logs.

Revision history for this message
Steve Langasek (vorlon) wrote :

Not a bug in upstart. The upstart logs contain whatever output the jobs in question generate.

Changed in upstart (Ubuntu):
status: New → Invalid
Revision history for this message
Steve Langasek (vorlon) wrote :

> mountall.log with "fsck von util-linux 2.20.1
> /dev/sda1: sauber, 205747/9199616 Dateien, 16090003/36781311 Blöcke".

> This looks more useful but I'm wondering if this shouldn't go better
> into /var/log/boot.log too.

I disagree.

Changed in mountall (Ubuntu):
status: New → Opinion
Revision history for this message
Steve Langasek (vorlon) wrote :

> It looks not intended that the same sysctl options are logged in 2 different
> files. Maybe it is even not intended to create any of these both logs.

This is an instantiated job which is run twice on boot, and the logs for a job are per-instance. So this is the expected logging behavior.

I have no opinion on whether the sysctl commands should be echoed at all.

Revision history for this message
Removed by request (removed3425744) wrote :

> Not a bug in upstart. The upstart logs contain whatever output the jobs in question generate.

I have not added upstart because the logs as a whole but because container-detect.log belongs to it. What do you think about the output of container-detect.log?

Revision history for this message
Steve Langasek (vorlon) wrote :

ah, fair point, /var/log/upstart/container-detect.log doesn't look very good either.

Actually, my log shows a different bug on systems with /usr as a separate partition:

/proc/self/fd/9: 18: /proc/self/fd/9: cut: not found
container-detect stop/pre-start, process 459

Changed in upstart (Ubuntu):
status: Invalid → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.