systemd: Yet Another Init Replacement

DarkSniper · 2012-02-13 04:38:49

Ah, I see now! I was able to locate that post and everything seems to be working well with journal. My biggest issue was not knowing how to read the journal, but I found that systemd-journalctl was the command I needed (a log that you can't read would be pretty useless).
As for lxdm, I think it might have been the BFQ option on linux-ck that was causing issues for some reason (it's caused instability in the past for me). A recompile without it seems to have solved it.

65kid · 2012-02-13 12:36:07

eworm wrote:

I have some problems with systemd-4[01]-1: lightdm starts up, when logging in my user session is killed by systemd-logind.
Regarding to /var/log/lightdm/lightdm.log it is sending SIGTERM to lightdm. Removing "kill-session-processes=1" from /etc/pam.d/lightdm does not have an effect. Anybody else with this problem? Any ideas what could go wrong?
Anything is fine with systemd-39-2.

Same here with lightdm / systemd-42. It works fine when I start lightdm manually from the console, so I guess this must be a problem with the lightdm.service file?!

eworm · 2012-02-13 12:45:09

65kid wrote:

eworm wrote:
I have some problems with systemd-4[01]-1: lightdm starts up, when logging in my user session is killed by systemd-logind.
Regarding to /var/log/lightdm/lightdm.log it is sending SIGTERM to lightdm. Removing "kill-session-processes=1" from /etc/pam.d/lightdm does not have an effect. Anybody else with this problem? Any ideas what could go wrong?
Anything is fine with systemd-39-2.
Same here with lightdm / systemd-42. It works fine when I start lightdm manually from the console, so I guess this must be a problem with the lightdm.service file?!

No, seems to be a problem of how lightdm handels pam session for the greeter. Here are the discussions on systemd-devel mailing list:
http://lists.freedesktop.org/archives/s … 04444.html
http://lists.freedesktop.org/archives/s … 04466.html

BTW, it works with lxdm, so using that until lightdm is fixed.

ratcheer · 2012-02-13 12:46:41

Is the only change "cups: udevadm moved", or am I missing something?

Tim

BasT · 2012-02-13 12:54:58

falconindy wrote:

sidneyk wrote:
If I understand correctly from Dave's announcement in the mailing list, journal basically is systemd's logger. According to his announcement, you no longer need syslog-ng or rsyslog or the such, unless you've changed the defaults.
My post was slightly misleading. The journal is not a direct replacement for syslog, but most desktop users can get away without the need for a syslog with the journal in place. If you really want to save logs, create /var/log/journal and the journal will log there (including doing rotation).
sidneyk wrote:
If you do use syslog-ng or another logger then systemd passes control from the journal back to it after or at some point during boot, if I understand correctly.
No, /dev/log belongs to the journal now. It's hands off for any other logger. If you want to use another logger, messages are forwarded via a message queue to /run/systemd/journal/socket. You should be subscribing to messages here instead.

So journald doesnt save logs (i.e. they get lost on reboot)?
If so, how do I get rsyslog to subscribe to the new socket?

falconindy · 2012-02-13 13:14:11

BasT wrote:

So journald doesnt save logs (i.e. they get lost on reboot)?

Read again, perhaps?

falconindy wrote:

If you really want to save logs, create /var/log/journal and the journal will log there (including doing rotation).

BasT wrote:

If so, how do I get rsyslog to subscribe to the new socket?

Change your rsyslog config to listen to /run/systemd/journal/socket instead of /dev/log.

Cdh · 2012-02-13 16:46:23

Nobody else unable to boot after a recent update? I got a kernel panic right after e4rat so I used init=/bin/bash and ran systemd "manually" and it had an undefined symbol in udev related stuff. If needed I can provide the exact message.

Edit: Solved by removing the stray /lib/libudev* libs leftover from the previous version of udev, new udev has its libs in /usr/lib/libudev*

Last edited by Cdh (2012-02-14 18:59:52)

crabman · 2012-02-13 17:28:23

after installing systemd-sysvcompat (and uninstalling initscripts) my LANG variable ist set properly anymore.:

$ cat /etc/locale.conf
LANG=de_DE.utf8

$ locale
LANG=
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=

is that a bug or do i have to add my own /etc/profile.d/locale.sh?

the.ridikulus.rat · 2012-02-13 17:47:18

falconindy wrote:

BasT wrote:
If so, how do I get rsyslog to subscribe to the new socket?
Change your rsyslog config to listen to /run/systemd/journal/socket instead of /dev/log.

Which line to change? Current rsyslog.conf

# if you experience problems, check
# http://www.rsyslog.com/troubleshoot for assistance

# rsyslog v3: load input modules
# If you do not load inputs, nothing happens!
# You may need to set the module load path if modules are not found.

$ModLoad immark   # provides --MARK-- message capability
$ModLoad imuxsock # provides support for local system logging (e.g. via logger command)
$ModLoad imklog   # kernel logging (formerly provided by rklogd)

# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.*                                                 /dev/console

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none                -/var/log/messages

# The authpriv file has restricted access.
authpriv.*                                              /var/log/secure

# Log all the mail messages in one place.
mail.*                                                  -/var/log/maillog


# Log cron stuff
cron.*                                                  -/var/log/cron

# Everybody gets emergency messages
*.emerg                                                 *

# Save news errors of level crit and higher in a special file.
uucp,news.crit                                          -/var/log/spooler

# Save boot messages also to boot.log
local7.*                                                /var/log/boot.log

# Remote Logging (we use TCP for reliable delivery)
# An on-disk queue is created for this action. If the remote host is
# down, messages are spooled to disk and sent when it is up again.
#$WorkDirectory /rsyslog/spool # where to place spool files
#$ActionQueueFileName uniqName # unique name prefix for spool files
#$ActionQueueMaxDiskSpace 1g   # 1gb space limit (use as much as possible)
#$ActionQueueSaveOnShutdown on # save messages to disk on shutdown
#$ActionQueueType LinkedList   # run asynchronously
#$ActionResumeRetryCount -1    # infinite retries if host is down
# remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional
#*.* @@remote-host:514


# ######### Receiving Messages from Remote Hosts ########## 
# TCP Syslog Server:
# provides TCP syslog reception and GSS-API (if compiled to support it)
#$ModLoad imtcp.so  # load module
#$InputTCPServerRun 514 # start up TCP listener at port 514

# UDP Syslog Server:
#$ModLoad imudp.so  # provides UDP syslog reception
#$UDPServerRun 514 # start a UDP syslog server at standard port 514

systemd-journald-conf

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU General Public License as published by
#  the Free Software Foundation; either version 2 of the License, or
#  (at your option) any later version.
#
# See system-journald.conf(5) for details

[Journal]
Compress=yes
#RateLimitInterval=10s
#RateLimitBurst=200
#SystemMaxUse=
#SystemKeepFree=
#SystemMaxFileSize=
#SystemMinFileSize=
#RuntimeMaxUse=
#RuntimeKeepFree=
#RuntimeMaxFileSize=
#RuntimeMinFileSize=
ForwardToSyslog=yes
ForwardToKMsg=no
ForwardToConsole=no
ImportKernel=yes

systemd/system.conf

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU General Public License as published by
#  the Free Software Foundation; either version 2 of the License, or
#  (at your option) any later version.
#
# See systemd.conf(5) for details

[Manager]
LogLevel=info
LogTarget=journal-or-kmsg
LogColor=yes
LogLocation=yes
#DumpCore=yes
#CrashShell=no
ShowStatus=yes
SysVConsole=yes
#CrashChVT=1
#CPUAffinity=1 2
MountAuto=yes
SwapAuto=yes
#DefaultControllers=cpu
#DefaultStandardOutput=journal
#DefaultStandardError=inherit
#JoinControllers=cpu,cpuacct

What is systemd-logind.conf for?

t-8ch · 2012-02-13 18:33:39

crabman wrote:

after installing systemd-sysvcompat (and uninstalling initscripts) my LANG variable ist set properly anymore.

Got the same issue

shouldn't systemd-localed.service be responsible for this?

$ systemctl status systemd-localed.service
systemd-localed.service - Locale Service
   Loaded: loaded (/lib/systemd/system/systemd-localed.service; static)
   Active: inactive (dead)
   CGroup: name=systemd:/system/systemd-localed.service

Last edited by t-8ch (2012-02-13 19:05:42)

falconindy · 2012-02-13 19:24:29

crabman wrote:

is that a bug or do i have to add my own /etc/profile.d/locale.sh?

Provide your own, or use ~/.pam_environment.

t-8ch wrote:

shouldn't systemd-localed.service be responsible for this?

Nope. localed is an interface for GUI tools to get/set the locale from DBus, especially in the case of a read-only root.

Last edited by falconindy (2012-02-13 19:25:51)

crabman · 2012-02-13 19:55:18

falconindy wrote:

crabman wrote:
is that a bug or do i have to add my own /etc/profile.d/locale.sh?
Provide your own, or use ~/.pam_environment.

Thanks for the quick reply. Ive added

LANG=de_DE.utf-8

to /etc/environment and

session     required    pam_env.so

to /etc/pam.d/kde. Now everything works fine.

Shouldn't this be set by the DE or systemd according to the value in /etc/locale.conf? Or at least the /etc/pam.d/ files contain the pam_env.so line by default?

eworm · 2012-02-14 09:13:50

I removed initscripts, initscripts-systemd and sysvinit, then installed systemd-sysvcompat.
Anything is fine so far, except the rc-local.service was removed as well. What is supposed to run /etc/rc.local or is there any replacement?

eworm · 2012-02-14 09:28:57

Oh, another problem: mkinitcpio hooks 'keymap' and 'consolefont' complain about missing /etc/rc.conf.
Will anybody fix that?

eworm · 2012-02-14 09:43:50

Uh, /bin/pidof belongs to sysvinit... How to get that back?

falconindy · 2012-02-14 13:55:08

eworm wrote:

I removed initscripts, initscripts-systemd and sysvinit, then installed systemd-sysvcompat.
Anything is fine so far, except the rc-local.service was removed as well. What is supposed to run /etc/rc.local or is there any replacement?

rc.local is a dumping ground for things you're too lazy to order. Write services for them. If you insist on keeping this crap around, there's services for rc.local in systemd-initscripts (I realize it conflicts with systemd-sysvcompat indirectly).

eworm wrote:

Oh, another problem: mkinitcpio hooks 'keymap' and 'consolefont' complain about missing /etc/rc.conf.
Will anybody fix that?

Nope. You can bring back rc.conf and use something like:

. /etc/vconsole.conf
. /etc/locale.conf
LOCALE=$LANG CONSOLEMAP=$KEYMAP CONSOLEFONT=$FONT

eworm wrote:

Uh, /bin/pidof belongs to sysvinit... How to get that back?

pgrep would like to have a word with you... As would fluxBB with regard to the "edit" button.

sidneyk · 2012-02-15 12:07:16

Here is what I've observed, nothing more, nothing less. I have the latest systemd and systemd-arch-units installed from the official repositories. I have uninstalled initscripts and sysvinit and installed systemd-sysvcompat. Reboot / shutdown, etc. work as expected. In my simple mind, I had the thought that I now should be able to take the 'init=/bin/systemd' out of my kernel command line. Oops, that didn't work so well. Upon reboot, I get as far as an error telling me that my root file system has been mounted, but that the file '/sbin/init' does not exist and I'm on my own. Of course, I know it exists because I checked that just prior to rebooting, at least the symlink exists that was installed with systemd-sysvcompat. I also tried creating a different link for '/sbin/init' pointing to '/lib/systemd/systemd', not know if the 2 levels of symlinks were the problem, but got the same results.

After that, I edited back in the 'init=/bin/systemd' to my kernel command line so that I can boot. I then was poking around in the file sytem and took a look at '/lib/initcpio/init' and '/lib/initcpio/init_functions'. I discovered if I change this one line in '/lib/initcpio/init' from 'init=${init:-/sbin/init}' to 'init=${init:-/bin/systemd}' then I can boot my system without the 'init=/bin/systemd' on the kernel command line. Of course, I backed up the original file just in case and I realize that it may be overwritten the next time that makeinitcpio is updated. I also regenerated my kernel images and grub.cfg before rebooting. Everything seems to work fine and I believe that I now have what may be called a more 'native' systemd setup.

My question is does this break anything I'm not aware of or is there any other danger in doing this?

falconindy · 2012-02-15 14:03:50

sidneyk wrote:

Here is what I've observed, nothing more, nothing less. I have the latest systemd and systemd-arch-units installed from the official repositories. I have uninstalled initscripts and sysvinit and installed systemd-sysvcompat. Reboot / shutdown, etc. work as expected. In my simple mind, I had the thought that I now should be able to take the 'init=/bin/systemd' out of my kernel command line. Oops, that didn't work so well. Upon reboot, I get as far as an error telling me that my root file system has been mounted, but that the file '/sbin/init' does not exist and I'm on my own. Of course, I know it exists because I checked that just prior to rebooting, at least the symlink exists that was installed with systemd-sysvcompat. I also tried creating a different link for '/sbin/init' pointing to '/lib/systemd/systemd', not know if the 2 levels of symlinks were the problem, but got the same results.

My fault. symlink was created improperly. I'll fix this later today. If you create the link as "/sbin/init -> ../bin/systemd", it'll work. As is, the initramfs tries to execute /bin/systemd on the ramfs itself.

sidneyk · 2012-02-16 04:04:31

falconindy wrote:

sidneyk wrote:
Here is what I've observed, nothing more, nothing less. I have the latest systemd and systemd-arch-units installed from the official repositories. I have uninstalled initscripts and sysvinit and installed systemd-sysvcompat. Reboot / shutdown, etc. work as expected. In my simple mind, I had the thought that I now should be able to take the 'init=/bin/systemd' out of my kernel command line. Oops, that didn't work so well. Upon reboot, I get as far as an error telling me that my root file system has been mounted, but that the file '/sbin/init' does not exist and I'm on my own. Of course, I know it exists because I checked that just prior to rebooting, at least the symlink exists that was installed with systemd-sysvcompat. I also tried creating a different link for '/sbin/init' pointing to '/lib/systemd/systemd', not know if the 2 levels of symlinks were the problem, but got the same results.
My fault. symlink was created improperly. I'll fix this later today. If you create the link as "/sbin/init -> ../bin/systemd", it'll work. As is, the initramfs tries to execute /bin/systemd on the ramfs itself.

Apparently, you are much better at this than I. I installed the updated systemd-sysvcompat package just now and before rebooting I changed the /lib/initcpio/init file back to it's original version, where init is pointing to /sbin/init and it works now like a charm with no 'init=/bin/systemd' kernel command line option. I was missing the '..' part in the symlink. I'm not experienced enough yet to know that that made a difference. So, after I played around with creating some links to experiment on, I finally figured it out. I was just thinking the '..' was just some shorthand or something for the listing, not realizing that it was signifying, apparently, "back 1 directory level from the directory we're running from". I always thought that it was good enough to say 'sudo ln -sf /lib/systemd/systemd /sbin/init', which is what I tried and why it didn't work, as you said. Now I know that I needed to say 'sudo ln -sf ../lib/systemd/systemd ../sbin/init'. Thanks for teaching me something new and thanks for all your work on this project.

ron9 · 2012-02-16 09:28:17

After update to v43 I get in journal:

systemd-vconsol[91]: /bin/setfont failed with error code 1

I find setfont in /usr/bin...

alex_pa · 2012-02-18 21:03:03

I installed systemd a few days ago and after reading some manuals and a little tweaking I have everything working, except one thing: I'm unable to shutdown or reboot the system from kde session, it throws me back to kdm login screen instead of shutdown/reboot. But I can shutdown/reboot from kdm itself. Here are some lines from logs that I suspect to be related to this problem:

ACPI group/action undefined: cd/stop / CDSTOP
Unregistered Authentication Agent for unix-session:/org/freedesktop/ConsoleKit/Session1 (system bus name :1.32, object path /org/kde/PolicyKit1/AuthenticationAgent, locale ru_UA.UTF-8)
:0[371]: pam_unix(kde-np:session): session closed for user alex
Removed session c1.

These messages appear in the log just before kdm 'restarts'
Can someone help me to figure out what I'm missing and how to fix that?

bzt · 2012-02-18 22:08:45

@alex_pa

I had the same problem with GNOME/GDM. Shutting down from the session threw me back at GDM, I could not even shutdown/reboot from there. Earlier this day, I have discovered the solution to my problem in this very thread, maybe it helps you too:

https://bbs.archlinux.org/viewtopic.php … 26#1030926

Creating the two symlinks as suggested by falconindy did not help me at first, but then I created another symlink of /bin/systemctl at /sbin/shutdown and since then graphical shutdown and reboot work again.

alex_pa · 2012-02-19 12:18:54

@bzt
I created a symlink '/bin/systemctl -> /sbin/shutdown' and unfortunately it didn't work for me, nothing changed. So it must be something else.

lucke · 2012-02-19 12:30:57

I have the same problem as alex_pa - restarting/shutting down from KDE brings me to kdm. It was working some days ago, it seems to work when I start kdm manually, not via .service file. I've noticed it after moving to sysvcompat (I rarely restart), but moving back to the sysvinit package didn't help, neither did downgrading systemd. Perhaps the consolekit error is the key indeed.

alex_pa · 2012-02-19 16:47:20

Ok, looks like we have a bug report on this, and only kdm+kde combination affected

Arch Linux

#1151 2012-02-13 04:38:49

Re: systemd: Yet Another Init Replacement

#1152 2012-02-13 12:36:07

Re: systemd: Yet Another Init Replacement

#1153 2012-02-13 12:45:09

Re: systemd: Yet Another Init Replacement

#1154 2012-02-13 12:46:41

Re: systemd: Yet Another Init Replacement

#1155 2012-02-13 12:54:58

Re: systemd: Yet Another Init Replacement

#1156 2012-02-13 13:14:11

Re: systemd: Yet Another Init Replacement

#1157 2012-02-13 16:46:23

Re: systemd: Yet Another Init Replacement

#1158 2012-02-13 17:28:23

Re: systemd: Yet Another Init Replacement

#1159 2012-02-13 17:47:18

Re: systemd: Yet Another Init Replacement

#1160 2012-02-13 18:33:39

Re: systemd: Yet Another Init Replacement

#1161 2012-02-13 19:24:29

Re: systemd: Yet Another Init Replacement

#1162 2012-02-13 19:55:18

Re: systemd: Yet Another Init Replacement

#1163 2012-02-14 09:13:50

Re: systemd: Yet Another Init Replacement

#1164 2012-02-14 09:28:57

Re: systemd: Yet Another Init Replacement

#1165 2012-02-14 09:43:50

Re: systemd: Yet Another Init Replacement

#1166 2012-02-14 13:55:08

Re: systemd: Yet Another Init Replacement

#1167 2012-02-15 12:07:16

Re: systemd: Yet Another Init Replacement

#1168 2012-02-15 14:03:50

Re: systemd: Yet Another Init Replacement

#1169 2012-02-16 04:04:31

Re: systemd: Yet Another Init Replacement

#1170 2012-02-16 09:28:17

Re: systemd: Yet Another Init Replacement

#1171 2012-02-18 21:03:03

Re: systemd: Yet Another Init Replacement

#1172 2012-02-18 22:08:45

Re: systemd: Yet Another Init Replacement

#1173 2012-02-19 12:18:54

Re: systemd: Yet Another Init Replacement

#1174 2012-02-19 12:30:57

Re: systemd: Yet Another Init Replacement

#1175 2012-02-19 16:47:20

Re: systemd: Yet Another Init Replacement

Board footer