Bug 4213 - Since last 2 kernels (and boots) systemd does not start syslog.target
Summary: Since last 2 kernels (and boots) systemd does not start syslog.target
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: Normal major
Target Milestone: ---
Assignee: Colin Guthrie
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 2120
  Show dependency treegraph
 
Reported: 2012-01-21 13:29 CET by Dick Gevers
Modified: 2012-01-27 09:36 CET (History)
2 users (show)

See Also:
Source RPM: systemd-38-8.mga2
CVE:
Status comment:


Attachments

Description Dick Gevers 2012-01-21 13:29:53 CET
Description of problem:

/usr and /var are on same partition as root partition, or '/'

Booting soon after roll out of kernel-server-3.2.1-1.mga2-1-1.mga2 and of
kernel-server-3.2.1-2.mga2-1-1.mga2, in each case with current Cauldron (and so latest systemd from that date and time), I have a non-running syslog:

# systemctl status syslog.target 
syslog.target - Syslog
    Loaded: loaded (/lib/systemd/system/syslog.target; static)
    Active: inactive (dead)

# systemctl start syslog.target 

# systemctl enable syslog.target 
Warning: unit files do not carry install information. No operation executed.

# systemctl status syslog.target 
syslog.target - Syslog
          Loaded: loaded (/lib/systemd/system/syslog.target; static)
          Active: active since Sat, 21 Jan 2012 12:07:09 +0000; 19s ago
Dick Gevers 2012-01-21 13:30:23 CET

Blocks: (none) => 2120

Dick Gevers 2012-01-21 13:39:34 CET

Blocks: 2120 => (none)
Summary: Since last 2 kernels (and boots) systemd deos not start syslog.target => Since last 2 kernels (and boots) systemd does not start syslog.target

Comment 1 Dick Gevers 2012-01-21 13:41:58 CET
Sorry for bad browswer/bugzilla interaction :((

Blocks: (none) => 2120

Comment 2 Dick Gevers 2012-01-21 21:49:53 CET
Confirmed: seen on 2 Cauldron machines now.
Comment 3 D Morgan 2012-01-25 02:34:30 CET
do you have /etc/systemd/system/syslog.service ?

CC: (none) => dmorganec

Comment 4 Dick Gevers 2012-01-25 20:34:24 CET
Certainly; since months:

stat /etc/systemd/system/syslog.service

 File: `/etc/systemd/system/syslog.service' -> `/lib/systemd/system/rsyslog.service'
  Size: 35              Blocks: 0          IO Block: 4096   symbolic link
Device: 805h/2053d      Inode: 411859      Links: 1
Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2012-01-24 19:40:41.151379063 +0000
Modify: 2012-01-18 20:09:56.105242553 +0000
Change: 2012-01-18 20:09:56.105242553 +0000
 Birth: -

Similar on the other cauldron machine.
Comment 5 D Morgan 2012-01-26 13:09:32 CET
is rsyslog service started ?
Comment 6 Colin Guthrie 2012-01-26 13:15:52 CET
You have to make sure that rsyslog.service is enabled

Can you provide output of "systemctl status rsyslog.service"?

(that said, I think rsyslog should have a "WantedBy=syslog.target" rather than "WantedBy=multi-user.target" which is has currently but that doesn't fully matter for the current issue).

CC: (none) => mageia

Comment 7 Dick Gevers 2012-01-26 19:10:06 CET
To c#5 and c#6 no syslog is not started: that is the bug. And yes it is enabled (all this is in the bugreport). In fact it is enabled since several months. But still it does not start with the last 2 reboots (equals last 2 new kernels in Cauldron).

Start works, enable seems to work, but the evidence is that on reboot it is not started.
Comment 8 Colin Guthrie 2012-01-26 19:14:00 CET
We were both talking about rsyslog.service, not syslog.service.

syslog.service should be a symlink to rsyslog.service, but you've not showing anything related to the status of rsyslog.service directly (just showing status' of syslog.target above).

Essentially, this symlink should exist: /etc/systemd/system/multi-user.target.wants/rsyslog.service

If it's not, just type "systemctl enable rsyslog.service" and it should enable it and allow a normal boot. If not, please provide output of systemctl status rsyslog.service.

Status: NEW => ASSIGNED
Assignee: bugsquad => mageia

Comment 9 Dick Gevers 2012-01-27 09:36:53 CET
Colin: Sorry my bad :(

Symlink exists and rebooting to kernel 3.2.2-1 the problems is fixed (although I did not change anything). So closing as resolved.

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED


Note You need to log in before you can comment on or make changes to this bug.