Siduction Forum
Siduction Forum => Siduction News => Topic started by: devil on 2013/05/31, 20:05:35
-
Who uses systemd already? Tell us your impressions, pros and cons and any tricks and cheats you found. Tell us what needs to be handled differently and what does not work as expected.
For whoever does not yet use it, but wants to understand it, here is the programmer himself busting the myths that have grown over the years: http://0pointer.de/blog/projects/the-biggest-myths.html
Please also tell us if you like us to include systemd, when and why.
Thanks in advance for helping us to make a good decision if to include systemd in siduction sometime this year or not.
greetz
devil
-
Will there be a migration tool provided to migrate existing initscripts to systemd?
-
I don't want systemd, so if you add it, please try to make it an option.
Tim
-
I don't want systemd, so if you add it, please try to make it an option.
Tim
I second that...perhaps make this a setting in the installer
-
Tim,
would you mind telling us why?
greetz
devil
-
Sure. Others have stated this much better than I can, but the ideas came to me as soon as I started seeing what systemd does in Arch Linux, about a year ago. It not only takes the responsibilities of an init system, but also the functions of udev, dbus, system logging, and possibly others.
In my opinion, this major bundling of functionality reduces my software freedom of choice. It does not fit with the Linux principle of "do one thing and do it right".
Maybe my thinking is unsound, but that is the way I feel about it.
Thanks,
Tim
-
hi all,
I systemd tested and found to have two virtual machines such as the the run level (there are actually no longer in systemd) 3 and 5 do not fit anymore. Also from the Grub boot manager I can not boot into runlevel third Otherwise, I can report a very fast boot process, which is minden least shortened by half (although not measured).
I would find it very beneficial when siduction soon switching to systemd.
-
...
I would find it very beneficial when siduction soon switching to systemd.
I am quite sure devil did start this survey to get a feeling of how solid systemd currently is. And I am also sure he and the other team members won't decide to activate systemd *by default* until it is near to rock solid, easily supportable and managable in almost each situation by the less skilled siduction users.
Doing otherwise would make siduction less attractive and lead to a more elite distribution.
BTW, from the few words we can read so far about personal experience with systemd I am afraid activating it soon would raise not only my blood pressure in many occasions ... ;-)
-
I admit I am only a spectator to the systemd development. But I did give the linked blog a thorough reading. I must say Lennart expresses himself well and makes excellent arguments for the design of systemd. Perhaps it's time for me to use a siduction VM and see what I can learn about systemd by installing it.
As far as the official released siduction, well, being sid, I would think we should support "new" whenever it is also "better". If it can be offered at first as an installation option (I don't actually know whether that is possible), then we can really find out how much people love it or hate it.
-
I have not tested as of yet, doing a google search on it and reading, I might not.
The question is, does systemd actually accomplish anything better ?
I don't care if it boots my system faster, (starting services in parallell) that, to me, is not a reason at all to use it. I, personally could care less.
If my system took 3-5 minutes to boot and was totally stable and worked fine once booted, I am happy.
So many people are concerned about boot time, I could care less. (were talking desktops here, a "work" environment "servers, patches, downtime, etc" might be different).
For administration, nothing is simpler than sysvinit
A couple of links (old)
http://www.jonmasters.org/blog/2011/04/29/response-to-why-systemd/
http://monolight.cc/2011/05/the-systemd-fallacy/
http://0pointer.de/blog/projects/why.html
https://fosdem.org/2013/schedule/event/debian_systemd/
http://wiki.debian.org/systemd
http://forums.debian.net/viewtopic.php?f=10&t=103479
In the end, Choice is good
-
A key advantage of systemd is, besides the parallelization of services, even very early in the boot process, the onset of logging (journald). This helps a lot better than the "old" syslog service in the search of problems. For this reason alone I would want to use systemd already.
-
Well, I can now testify that it was a 20-minute project, mainly reading the Debian wiki, to install systemd on my siduction RazorQt VM. I put systemd-sysv on hold to overcome the conflict with sysvinit. The VM boots flawlessly -- there were no issues at all. So maybe there could be some issues with hardware -- I'll try it on a laptop when time permits.
EDIT: Question: Since init 3 is no longer effective on a systemd installation, what is the recommended method to stop the xserver before dist-upgrade? I did this:
# service lightdm stop && exit
Is that sufficient?
-
I can't remember, I *think (what I have in my notes)
init 3
graphical.target stop service
init 5
service start graphical.target
A good read
http://www.freedesktop.org/wiki/Software/systemd/
I believe for fedora (cheat sheet) not sure with debian, I don't use so can't test
http://crashmag.net/useful-systemd-commands
-
Results of the Debian systemd survey (2013-05-27)
http://people.debian.org/~stapelberg//2013/05/27/systemd-survey-results.html
-
Well, I can now testify that it was a 20-minute project, mainly reading the Debian wiki, to install systemd on my siduction RazorQt VM. I put systemd-sysv on hold to overcome the conflict with sysvinit. The VM boots flawlessly -- there were no issues at all. So maybe there could be some issues with hardware -- I'll try it on a laptop when time permits.
EDIT: Question: Since init 3 is no longer effective on a systemd installation, what is the recommended method to stop the xserver before dist-upgrade? I did this:
# service lightdm stop && exit
Is that sufficient?
Good info for creating a wiki for switching an existing install which is currently using SysV-style initscripts to Systemd. If there are a lot of benefits for switching to Systemd vis a vis SysV then perhaps systemd should be installed in siduction by default on a fresh install.
From what I see in that Debian devel list posting, the system logs are in a binary format vs a plaintext format for SysV. Are tools provided to read these binary system logs whenever debugging some issue or in looking for errors to document in some bug report?
-
I think a lot of customizations will be lost
I don't think /lib/lsb/init-functions would be editable anymore, I am sure there is a lot more that you won't be able to customize to "your" liking.
How is this going to effect the build process of siduction ?
-
Are tools provided to read these binary system logs whenever debugging some issue or in looking for errors to document in some bug report?
Yes, the command "systemd-journalctl" is the tool for listing the journal into a "most" window. I haven't learned the options yet, but the basic command works as advertised.
"man systemd-journalctl" looks very complete.
-
Please note: My objections to systemd have nothing to do with the technical merits of either systemd or sysvinit.
Tim
-
Here is a article from the Debian-Wiki: http://wiki.debian.org/systemd
-
Are tools provided to read these binary system logs whenever debugging some issue or in looking for errors to document in some bug report?
Yes, the command "systemd-journalctl" is the tool for listing the journal into a "most" window. I haven't learned the options yet, but the basic command works as advertised.
"man systemd-journalctl" looks very complete.
Great, thanks. Also it might be useful to write a script akin to siduction-paste to highlight things of interest in the systemd logs and put them into a pastebin as part of troubleshooting or bug reporting
-
You can either look at man journalctl or read on it at: http://www.dsm.fordham.edu/cgi-bin/man-cgi.pl?topic=journalctl&sect=1v or read Lennarts blog about it on http://0pointer.de/blog/projects/journalctl.html
greetz
devil
-
I have a laptop that I use mainly for experiments -- why it is still running I don't know. :mrgreen: It only took 5 minutes to install systemd, since I am already so experienced. This one runs on an SSD, and it was already booting up pretty fast, but I was amazed at the boot on systemd -- between 9 and 10 seconds from grub to kdm, and I have done nothing special to tweak it.
Don't forget to install the libpam-systemd and systemd-sysv packages, and to put systemd-sysv on hold. Here's the hardware:
System: Host: delle6500 Kernel: 3.9-4.towo-siduction-amd64 x86_64 (64 bit)
Desktop: KDE 4.10.3 Distro: siduction 12.1-RC1 Desperado - kde - (201205152133)
Machine: System: Dell product: Latitude E6500 serial: 7XFD1J1
Mobo: Dell model: 0PP476 serial: .7XFD1J1.CN129619122714. Bios: Dell version: A14 date: 07/31/2009
CPU: Dual core Intel Core2 Duo CPU P8600 (-MCP-) cache: 3072 KB flags: (lm nx sse sse2 sse3 sse4_1 ssse3 vmx)
Clock Speeds: 1: 2401.00 MHz 2: 2401.00 MHz
Graphics: Card: NVIDIA G98M [Quadro NVS 160M]
X.org: 1.12.4 drivers: nouveau (unloaded: fbdev,vesa) tty size: 137x37 Advanced Data: N/A for root
Audio: Card: Intel 82801I (ICH9 Family) HD Audio Controller driver: snd_hda_intel
Sound: Advanced Linux Sound Architecture ver: k3.9-4.towo-siduction-amd64
Network: Card-1: Broadcom BCM4312 802.11b/g LP-PHY driver: b43-pci-bridge
IF: wlan0 state: up mac: 00:23:4e:ab:86:7a
Card-2: Intel 82567LM Gigabit Network Connection driver: e1000e
IF: eth1 state: down mac: 00:21:70:d4:d3:04
Drives: HDD Total Size: 120.0GB (44.2% used) 1: id: /dev/sda model: OCZ_VERTEX size: 120.0GB
Partition: ID: / size: 9.8G used: 7.8G (84%) fs: ext4 ID: swap-1 size: 1.61GB used: 0.00GB (0%) fs: swap
RAID: No RAID devices detected - /proc/mdstat and md_mod kernel raid module present
Sensors: System Temperatures: cpu: 44.5C mobo: N/A gpu: 42.0
Fan Speeds (in rpm): cpu: N/A
Info: Processes: 170 Uptime: 7 min Memory: 884.0/3948.5MB Client: Shell (bash) inxi: 1.9.7
-
Although I must admit I don't now very much what I'm doing but I belong to those who start and stop my laptop many times a day so I love a fast boot. I just took a chance and installed systemd, and yes it works and yes my laptop goes from grub to log in screen in 6 seconds :)
This is what I did: Installed systemd, libpam-systemd and systemd-sysv packages, and did put systemd-sysv on hold. Then rebooted.
Maybe or probably I will get into troubles on future d-u:s but that's then...
Edited: Hmm run into problem, the laptop will not shut down when using the menu at xfce, reboot works but not power off. So For now I have to do "poweroff" as root to be able to stop.
My system:Machine: System: LENOVO product: 6474BB4 version: ThinkPad T400
Mobo: LENOVO model: 6474BB4 Bios: LENOVO version: 7UET94WW (3.24 ) date: 10/17/2012
CPU: Dual core Intel Core2 Duo CPU P8600 (-MCP-) cache: 3072 KB flags: (lm nx sse sse2 sse3 sse4_1 ssse3 vmx) bmips: 9575.98
Clock Speeds: 1: 800.00 MHz 2: 800.00 MHz
Graphics: Card: Intel Mobile 4 Series Integrated Graphics Controller bus-ID: 00:02.0
X.Org: 1.12.4 drivers: intel (unloaded: fbdev,vesa) Resolution: 1440x900@60.3hz
GLX Renderer: Mesa DRI Mobile Intel GM45 Express GLX Version: 2.1 Mesa 8.0.5 Direct Rendering: Yes
Network: Card-1: Intel Ultimate N WiFi Link 5300 driver: iwlwifi ver: in-tree: bus-ID: 03:00.0
IF: wlan0 state: up mac: 00:16:ea:e6:27:3a
Card-2: Intel 82567LM Gigabit Network Connection driver: e1000e ver: 2.2.14-k port: 1840 bus-ID: 00:19.0
IF: eth0 state: down mac: 00:1c:25:99:37:a2
Drives: HDD Total Size: 120.0GB (38.3% used) 1: model: KINGSTON_SV300S3
Info: Processes: 140 Uptime: 8 min Memory: 420.2/3854.4MB Runlevel: 5 Gcc sys: 4.7.3
Client: Shell (bash 4.2.45) inxi: 1.8.47
-
I have experimented with and am using systemd in Arch/Bridge and Gentoo.
It is forced on you in Arch as is in many Arch spins.
Gentoo my change was by choice just to give it a whirl.
So, I like playing with systemd and the commands but as I use systemd for over a month I began to believe that the boot and process handling was superior to init.d
Simple to add systemd with apt-get and Debian kernels work fine with systemd also.
Of course towo's kernels being specialized may need a tweak or two or three like
CONFIG_DEVTMPFS=y
CONFIG_CGROUPS=y
Then I as in Gentoo I just modified my grub.cfg
# $EDITOR /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet init=/lib/systemd/systemd" <--- Change this line
# update-grub
All seems to work fine but I have no problems with the current init scripting model. Plus, my testing has shown this Distro (Siduction) in particular boots and shuts down as aggressively as my systemd converts.
At the end of the Day for Me, I see no need for systemd. Maybe if it spit fire or something else interesting.
While I am interested to a small Degree my Vote as a user is systemd NO
-
Does anyone have a working journal with systemd? Even though I have libsystemd-journal0 installed, my /var/log is still what it used to be, no /journal.
greetz
devil
-
If I call correctly, there is a simple one-time command to convert to journald logging. It may have been something as simple as creating the directory for it. I am sure there are good instructions on the Arch Wiki.
Tim
-
Edited: Hmm run into problem, the laptop will not shut down when using the menu at xfce, reboot works but not power off.
I also noticed what looks like a "hang" on restart or power off. Just wait a minute or two (or three) -- eventually it always completes on my hardware.
@devil I am working on the permanent journal question -- no answer yet.
Edit: I think I see the problem, down at the bottom of bug 691965 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691965). They could mention that in the wiki .... :(
-
Found that by default the journal goes volatile to /run/log. You need to add a line to /etc/systemd/systemd-journald.conf like
Storage=persistent to make it go to /var/log/journal. Not very user friendly yet.
greetz
devil
-
Edited: Hmm run into problem, the laptop will not shut down when using the menu at xfce, reboot works but not power off.
I also noticed what looks like a "hang" on restart or power off. Just wait a minute or two (or three) -- eventually it always completes on my hardware.
@devil I am working on the permanent journal question -- no answer yet.
Edit: I think I see the problem, down at the bottom of bug 691965 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691965). They could mention that in the wiki .... :(
Looks like it's working to switch of now, yet not failed today and it's fast at switch off also.
-
Found that by default the journal goes volatile to /run/log. You need to add a line to /etc/systemd/systemd-journald.conf likeStorage=persistent to make it go to /var/log/journal.
That works correctly on my desktop system. On a laptop and a netbook, it does not move the journal -- I still find it at /run/log/journal. Strange ...
-
Found that by default the journal goes volatile to /run/log. You need to add a line to /etc/systemd/systemd-journald.conf likeStorage=persistent to make it go to /var/log/journal.
That works correctly on my desktop system. On a laptop and a netbook, it does not move the journal -- I still find it at /run/log/journal. Strange ...
Then you might need to set that config option BEFORE switching over to systemd so that on the first start of systemd it should then create the journal in the proper place already
-
EDIT: Question: Since init 3 is no longer effective on a systemd installation, what is the recommended method to stop the xserver before dist-upgrade? I did this:
# service lightdm stop && exit
Is that sufficient?
Following up on this question, I believe the answer is "NO".
My reading of these FAQs (http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions/) (thanks piper), plus a little experimentation, leads me to think that the X server shutdown is like this, at the tty console:
# systemctl isolate multi-user.target
# service kdm stop
(or lightdm, gdm, slim, etc.)
and to restart X:
# systemctl isolate graphical.target && exit
-
I found from Debian Wiki (http://wiki.debian.org/systemd#Debugging_systemd) (http://wiki.debian.org/systemd#Debugging_systemd) that enabling LogTarget=syslog-or-kmsg in /etc/systemd/system.conf gives me the /var/log/syslog in addition to the one viewable with systemd-journalctl.
-
I found from Debian Wiki (http://wiki.debian.org/systemd#Debugging_systemd) (http://wiki.debian.org/systemd#Debugging_systemd) that enabling LogTarget=syslog-or-kmsg in /etc/systemd/system.conf gives me the /var/log/syslog in addition to the one viewable with systemd-journalctl.
Nice tip, so it must be possible to have a readable syslog along with the binary journal. That might be a good tip also for debugging to turn on regular syslog alongside systemd to make it easier to get any errors to document
-
I found from Debian Wiki (http://wiki.debian.org/systemd#Debugging_systemd) (http://wiki.debian.org/systemd#Debugging_systemd) that enabling LogTarget=syslog-or-kmsg in /etc/systemd/system.conf gives me the /var/log/syslog in addition to the one viewable with systemd-journalctl.
I set this on my laptop, and tested. I see it does make a /var/log/syslog file for each booted session, but it is not persistent -- a new log is started at each new boot.
Since a laptop or a netbook is not normally going to accumulate a lot of errors, without the user knowing something is wrong, it is not important (at least to me), to go back to prior booted sessions and look for errors on the laptop, like it might be on the desktop. But I would think it should be possible to set the log as persistent, same as the desktop, which is working correctly with a systemd log at /var/log/journal.
-
Why is systemd-journalctl not enough to view the logs?
Oh, and btw.: last nights core-meeting brought the decision to go for systemd (and secure-boot) for one of the next releases. I filed this bug today:
http://chili.siduction.org/issues/1246
greetz
devil
-
Good that siduction will adopt systemd, IMHO.
HOWEVER, the issue of a persistent journal is not resolved. For my fourth system, a laptop, I followed your process exactly. The edit to /etc/systemd/systemd-journald.conf was made before rebooting. Nevertheless, again I have only the /run/log/journal/logfile as a non-persistent log.
Possibly the newer version will fix this bug, but there is something about the log location that is not controllable in ver. 44.11.
Here is the latest hardware:
System: Host: latitude-D620 Kernel: 3.9-4.towo-siduction-amd64 x86_64 (64 bit, gcc: 4.7.3)
Desktop: KDE 4.10.3 (Qt 4.8.4) Distro: siduction 12.1.1 Desperado Reloaded - kde - (201206241901)
Machine: System: Dell product: Latitude D620 serial: 587F1D1
Mobo: Dell model: 0KX350 serial: .587F1D1.CN1296175N2438. Bios: Dell version: A10 date: 05/16/2008
CPU: Dual core Intel Core2 CPU T7200 (-MCP-) cache: 4096 KB flags: (lm nx sse sse2 sse3 ssse3 vmx) bmips: 7988.68
Clock Speeds: 1: 1000.00 MHz 2: 1000.00 MHz
Graphics: Card: NVIDIA G72M [Quadro NVS 110M/GeForce Go 7300] bus-ID: 01:00.0
X.org: 1.12.4 driver: nvidia tty size: 73x39 Advanced Data: N/A for root
Network: Card-1: Broadcom NetXtreme BCM5752 Gigabit Ethernet PCI Express driver: tg3 ver: 3.130 bus-ID: 09:00.0
IF: eth0 state: down mac: 00:18:8b:d6:2c:8f
Card-2: Intel PRO/Wireless 3945ABG [Golan] Network Connection driver: iwl3945 ver: in-tree:s bus-ID: 0c:00.0
IF: wlan0 state: up mac: 00:1b:77:37:e7:b5
Drives: HDD Total Size: 100.0GB (5.5% used) 1: model: Hitachi_HTS72101
Info: Processes: 152 Uptime: 37 min Memory: 762.3/3267.3MB Runlevel: 5 Gcc sys: 4.7.3
Client: Shell (bash 4.2.45) inxi: 1.9.7
-
Good that siduction will adopt systemd, IMHO.
HOWEVER, the issue of a persistent journal is not resolved. For my fourth system, a laptop, I followed your process exactly. The edit to /etc/systemd/systemd-journald.conf was made before rebooting. Nevertheless, again I have only the /run/log/journal/logfile as a non-persistent log.
Possibly the newer version will fix this bug, but there is something about the log location that is not controllable in ver. 44.11.
Here is the latest hardware:
System: Host: latitude-D620 Kernel: 3.9-4.towo-siduction-amd64 x86_64 (64 bit, gcc: 4.7.3)
Desktop: KDE 4.10.3 (Qt 4.8.4) Distro: siduction 12.1.1 Desperado Reloaded - kde - (201206241901)
Machine: System: Dell product: Latitude D620 serial: 587F1D1
Mobo: Dell model: 0KX350 serial: .587F1D1.CN1296175N2438. Bios: Dell version: A10 date: 05/16/2008
CPU: Dual core Intel Core2 CPU T7200 (-MCP-) cache: 4096 KB flags: (lm nx sse sse2 sse3 ssse3 vmx) bmips: 7988.68
Clock Speeds: 1: 1000.00 MHz 2: 1000.00 MHz
Graphics: Card: NVIDIA G72M [Quadro NVS 110M/GeForce Go 7300] bus-ID: 01:00.0
X.org: 1.12.4 driver: nvidia tty size: 73x39 Advanced Data: N/A for root
Network: Card-1: Broadcom NetXtreme BCM5752 Gigabit Ethernet PCI Express driver: tg3 ver: 3.130 bus-ID: 09:00.0
IF: eth0 state: down mac: 00:18:8b:d6:2c:8f
Card-2: Intel PRO/Wireless 3945ABG [Golan] Network Connection driver: iwl3945 ver: in-tree:s bus-ID: 0c:00.0
IF: wlan0 state: up mac: 00:1b:77:37:e7:b5
Drives: HDD Total Size: 100.0GB (5.5% used) 1: model: Hitachi_HTS72101
Info: Processes: 152 Uptime: 37 min Memory: 762.3/3267.3MB Runlevel: 5 Gcc sys: 4.7.3
Client: Shell (bash 4.2.45) inxi: 1.9.7
Why not file a bug report documenting your findings so that the systemd maintainers can hopefully find and fix that bug or provide clarification on how to properly configure persistent logging for systemd.
-
Why not file a bug report documenting your findings...
Well, I'm sitting here playing with ver. 44, and devil's info says ver. 214 will soon be coming into sid. So I want to see how the new version works before I start yelling about bugs. But if it's not fixed, I will file a bug.
-
Why not file a bug report documenting your findings...
Well, I'm sitting here playing with ver. 44, and devil's info says ver. 214 will soon be coming into sid. So I want to see how the new version works before I start yelling about bugs. But if it's not fixed, I will file a bug.
Hope the new version fixes the issues you encountered and if not then yell about bugs :)
-
Well, mkdir -p /var/log/journal does help in this case. And 44 is 14 months old, so there will be a ton of improvements. Documentations is already now very good, but takes time to read and grasp the new concepts.
greetz
devil
-
And (systemd-)44 is 14 months old, so there will be a ton of improvements.
The best for siduction was to have a Debian maintainer interested in systemd, who seeks a better experimental repo with real users and comes to siduction: Like Santa with his Kde interest!
At siduction there is no need to keep all archs in sync. To build here it should be easy enough. At Gentoo I hear the rumour of upstream systemd following RedHat special interests. But I hope these specials are margin: easy to adapt some single configs to Debian needs.
Documentations is already now very good, but takes time to read and grasp the new concepts.
If you don't want other than the default, then systemd just runs without need to read documentation ...
If some unit file would be missing, it will be easy to find it already at Arch or Fedora or Gentoo. Also writing yourself a unit isn't that a difficulty.
The recommendation I give is to not try Systemd with sysvinit-compatibility. It might work, but it is not needed and it obscures all of otherwise clean and transparent Systemd experience. And all I know is Debian Maintainers want to include every compatibility layer possible. Which is reasonable for the whole lot of Debian sponsors: Universities and other akademical institutes.
@agaida, what do you think of Systemd with experience of Arch distribuiton?
-
Hi devil,
do you have a link from a useful documentation (like in German) of systemd or journald? I have since found anything yet comprehensive.
-
Today I found a PEBKAC error was causing part of my issues -- on one laptop and the netbook which have SSDs, I had previously mounted /var/log on a tmpfs, so of course it was not possible for anything to be persistent including the systemd journal. (headslap here) By changing that setup, and then making the /var/log/journal directory, and the next item below, they're working correctly.
Then make the directory for /var/log/journal as devil says, and after reboot it is working correctly on the Dell laptop I posted above and my other computers. With these two things corrected, it looks like I can set the journal to be persistent at /var/log/journal on all my systems, so that's a closed issue.
HOWEVER, I believe we still need to develop correct guidance for taking the system to the level formerly known as "init 3" (no X server running) for d-u. Today I discovered that when you use:
systemctl isolate multiuser.target it also kills the ssh service, so that is no good for remote administration. I'll have to wait for one more knowledgeable to figure out a correct procedure for d-u on a systemd system.
-
There
http://fedoraproject.org/wiki/Systemd#How_do_I_change_the_runlevel.3F
is an alternative way to got to RL 3:
systemctl isolate runlevel3.target
Maybe (not tested by michaa7) this allows for multiuser including sshd without X? And/or it may depend on how RL3 (=runlevel3.target) is configured (RH vs. Debian vs. siduction)
-
Today I discovered that when you use:
systemctl isolate multi-user.target it also kills the ssh service
This was only half-correct. It actually kills networking.
Default installation does not create a runlevel3.target.
-
@dibl, you should link in what you need, on my Gentoo:
# ls -ll /etc/systemd/system/multi-user.target.wants/
insgesamt 0
lrwxrwxrwx 1 root root 35 6. Nov 2012 cups.path -> /usr/lib64/systemd/system/cups.path
lrwxrwxrwx 1 root root 38 25. Aug 2012 dhcpcd.service -> /usr/lib/systemd/system/dhcpcd.service
lrwxrwxrwx 1 root root 41 3. May 11:47 local-d-start.service -> /etc/systemd/system/local-d-start.service
lrwxrwxrwx 1 root root 40 4. Jun 17:44 remote-fs.target -> /usr/lib/systemd/system/remote-fs.target
lrwxrwxrwx 1 root root 47 25. Aug 2012 wpa_supplicant@wlan0.service -> /usr/lib/systemd/system/wpa_supplicant@.service
-
...
This was only half-correct. It actually kills networking.
...
Hmm, but maybe that's a bug, because from what I read in the net,
https://bugzilla.redhat.com/show_bug.cgi?id=743603
multi-user.target should have network enabled!
-
@dibl, you should link in what you need
Yep, now trying this:
root@imerabox:/etc/systemd/system/multi-user.target.wants# ln -s /lib/systemd/system/runlevel3.target runlevel3.target
EDIT: Nope -- no help there.
-
Isn't
runlevel3.target
just another name for
multi-user.target
in sysvinit-compatible mode?
I hope you will not get a circular dependency issue, because it might be an internal special name (synonym) for systemd.
[edit]I just found on Gentoo with systemd-204:
man systemd.special
runlevel2.target, runlevel3.target, runlevel4.target, runlevel5.target
These are targets that are called whenever the SysV compatibility code asks for runlevel 2, 3, 4, 5,
respectively. It is a good idea to make this an alias for (i.e. symlink to) multi-user.target (for runlevel
2) or graphical.target (the others)
By the way:
When dist-upgrading Debian-Sid it is not needed anymore to stop the X session, but safer. You can just stop your personal session and change via Ctrl+Alt+F3 to a non X console to do your DU as root.
Years ago an upgrade of dbus would have had an automatic restart of dbus and dependend services, which would have resulted in your session to stop and your root Konsole (doing DU) to also break/crash working. But I buged maintainers to stop that kind of nonsense.
-
I would think the multi-user.target would have the networking service. But under /lib/systemd/system there is no network.service, only network.target.
Perhaps it is sufficient to stop the Display Manager (kdm, gdm, lightdm, slim, etc.) for the d-u. That will shut down the gui, and then you can work at the tty console, as you say.
-
Today I found a PEBKAC error was causing part of my issues -- on one laptop and the netbook which have SSDs, I had previously mounted /var/log on a tmpfs, so of course it was not possible for anything to be persistent including the systemd journal. (headslap here) By changing that setup, and then making the /var/log/journal directory, and the next item below, they're working correctly.
Then make the directory for /var/log/journal as devil says, and after reboot it is working correctly on the Dell laptop I posted above and my other computers. With these two things corrected, it looks like I can set the journal to be persistent at /var/log/journal on all my systems, so that's a closed issue.
HOWEVER, I believe we still need to develop correct guidance for taking the system to the level formerly known as "init 3" (no X server running) for d-u. Today I discovered that when you use:
systemctl isolate multiuser.target it also kills the ssh service, so that is no good for remote administration. I'll have to wait for one more knowledgeable to figure out a correct procedure for d-u on a systemd system.
Should that directory actually be created by systemd already? if not hopefully that a future systemd package can set it all up properly or maybe tune settings at package install time via debconf
It would also be nice if there were some scripts included that can mimic the SysV runlevels for systemd and these can help people used to the sysv way of doing things with inits.
More good info for a wiki entry on systemd
-
I would think the multi-user.target would have the networking service. But under /lib/systemd/system there is no network.service, only network.target.
Perhaps it is sufficient to stop the Display Manager (kdm, gdm, lightdm, slim, etc.) for the d-u. That will shut down the gui, and then you can work at the tty console, as you say.
That should be safe enough to allow a d-u without causing any issues. Perhaps rebooting the system after a d-u that makes updates to core system packages is advisable
-
Only a sidenote to the survey:
According to
apt-cache rdepends kdm
apt-cache rdepends xserver-xorg
there is no dependency between the two packages.
So I'm not sure if stopping kdm really gets us the level of safety which we achive by switching to RL3 during d-u.
-
Only a sidenote to the survey:
According to
apt-cache rdepends kdm
apt-cache rdepends xserver-xorg
there is no dependency between the two packages.
So I'm not sure if stopping kdm really gets us the level of safety which we achive by switching to RL3 during d-u.
Isn't it safe when kdm AND Xorg completely shut down?
-
Isn't it safe when kdm AND Xorg completely shut down?
Right -- but what is that command, after systemd is installed?
-
So I'm not sure if stopping kdm really gets us the level of safety which we achive by switching to RL3 during d-u.
Today I made a little investigation about this, on my LXDE netbook and also on my KDE desktop. You guys can try it and see if it is the same for your systems.
When you are logged in to the GUI as a user on TTY7, open a terminal and run
px aux | most
When you scroll down the list, at a point you find a section that looks like this:
root 27343 0.0 0.0 26808 780 ? Ss 07:43 0:00 /usr/bin/kdm
.
.
.
root 27346 0.0 1.5 207128 91716 tty7 Ss+ 07:43 0:07 /usr/bin/X :0 vt7 -br -nolisten tcp -auth /var/run/xauth/A:0-t1v2
root 27364 0.0 0.0 0 0 ? S 07:43 0:00 [kworker/2:1]
root 27366 0.0 0.0 24344 1448 ? S 07:43 0:00 /sbin/udevd
root 27367 0.0 0.0 24344 1444 ? S 07:43 0:00 /sbin/udevd
root 27373 0.0 0.0 75268 2460 ? S 07:43 0:00 -:0
root 27489 0.0 0.0 0 0 ? S 08:59 0:00 [kworker/1:1]
root 27535 0.0 0.0 0 0 ? S 09:59 0:00 [flush-8:0]
root 27561 0.0 0.0 0 0 ? S 10:27 0:00 [kworker/0:0]
root 27569 0.0 0.0 0 0 ? S 10:35 0:00 [kworker/0:2]
don 27580 0.0 0.0 4324 696 ? Ss 10:38 0:00 /bin/sh /usr/bin/startkde
don 27626 0.0 0.0 12592 336 ? Ss 10:38 0:00 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session /usr/
don 27629 0.0 0.0 24468 880 ? S 10:38 0:00 /usr/bin/dbus-launch --exit-with-session /usr/bin/startkde
don 27630 1.2 0.0 35228 3128 ? Ss 10:38 0:01 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --ses
don 27670 0.0 0.0 4088 88 ? S 10:38 0:00 /usr/lib/kde4/libexec/start_kdeinit +kcminit_startup
don 27671 0.1 0.7 367672 46348 ? Ss 10:38 0:00 kdeinit4: kdeinit4 Running...
don 27672 0.0 0.4 373980 24608 ? S 10:38 0:00 kdeinit4: klauncher [kdeinit] --fd=9
don 27674 0.4 0.7 1417788 48716 ? Sl 10:38 0:00 kdeinit4: kded4 [kdeinit]
don 27690 0.1 0.2 285160 17080 ? S 10:38 0:00 /usr/bin/kglobalaccel
.
.
.
Now go to the console on tty1, log in as root, and issue:
service kdm stop
(or slim, gdm, lightdm, or whatever your DM is) and then run the same list of processes. On the two systems I looked at, all of the user processes were killed, as well as the X-related root processes including /usr/bin/X on tty7.
So it looks safe to me to run d-u after the DM is stopped. Right?
Of course if a new version of a video driver (or other hardware driver) is installed, we will still need to either unload/reload the applicable kernel module or reboot to run the new module.
-
...You guys can try it and see if it is the same for your systems.
As I am still reluctent enough to not enable systemd I can't, but ......open a terminal and run
px aux | most
I assume you meant ps, not px?
I then tried it like this:
ps aux | egrep "kdm|X"
which avoids searching and scrolling.
Intrestingliny here kdm is owned by root not theuser, probably due to me using fluxbox as DE.
Then I switched to tty1 (but still init 5), issued "etc/init.d/kdm stop" and ps aux | egrep "kdm|X" didn't show a running X. This indicates, while no package dependencies exist between kdm and x-server-org, that kdm is *configured* to start and stop X.
Acctually "etc/init.d/kdm start" brought back the kdm login screen (where I login to fluxbox, don't like slim a.o.).
So my warning some posting above seems unneccessary as we may assume that systemd does not change this behaviour.
-
I assume you meant ps, not px?
Ooops -- the old eyes are easily fooled by small text!
Interestingly here kdm is owned by root not theuser ...
No, KDM or the other DMs are root processes, because no one has logged into the system when they are launched. Apparently the X server process is a child of the DM, and the KDE user processes are all children of that one. Or something like that ... I'm way over my head on this stuff.
-
Interestingly here kdm is owned by root not theuser ...
No, KDM or the other DMs are root processes,..
You are right. Don't know how I came to an other idea ...
-
I've been using systemd 44-12 for a week or so and until the dist-upgrade last night I didn't see any problems, but, I'm having trouble with reboot. Even using Restart from the KDE menu the reboot hangs with the cursor in the upper left hand corner of the screen. Using ctrl-alt-delete, once, frees up whereever it's stuck, but, it still doesn't reboot until I use the "systemctl --force reboot" command.
I see some interesting lines in some of the log files, but, before I start trying to solve the problem, is there a more recent version that I can update to? Or, is anyone else seeing this?
-
Yes, I started seeing hangs on shutdown yesterday. So far I'm only seeing it on the two 32-bit systems that I have. I need to check the 64-bit systems -- so far no one has complained about them. Also running systemd 44-12 here.
EDIT: After updating, the 64-bit systems are showing the same issue. Either from the user X session, or from a root console login, the shutdown sequence hangs with a blinking cursor in the upper left corner, which is totally nonresponsive to the keyboard. Ctrl-Alt-Del will resume the shutdown sequence, which becomes a restart, not a shutdown/power off.
These systems are a variety of video hardware -- Intel, AMD, and Nvidia, so I'm confident that the issue is not directly graphics-related. And since it happens on a root tty1 console, with X shut down, I don't think it has anything to do with the X server, either.
-
I have the same issue since a few days but it's not happening every shutdown sometimes shutdown works. 64 bit xfce
-
While shutdown worked originally, last night, it failed. The only way I was able to power down was a cold halt.
There was an update to init-system-helpers in my last du. I'm going to check that out first.
-
I can see that when I press Ctrl-Alt-Del, the next bit that is executed is "Sending SIGTERM to remaining processes" followed by "Sending SIGKILL to remaining processes" and then it shuts down/restarts. So it is hanging before the running processes are killed off.
-
I am in England with very limited computer access so I can't test :(
-
You're seeing the same thing I am dibl. I found that "systemctl poweroff --force" works for shutdown. Without the --force, it just reboots, after a ctrl-alt-del to get past the stuck service.
Quote from "man systemctl poweroff"
If combined with --force shutdown of all running services is skipped, however all processes are killed and all file systems are unmounted or mounted read-only, immediately followed by the powering off.
So, one of the running services is holding up shutdown ... I guess.
I'm hoping journalctl will finally give us a way of logging the scroll from shutdown. I'd really like to see what shutdown is stuck on. I looked at dmesg and messages and many other logs and didn't come up with anything I thought was interesting.
Gotta work for a few days, so, I guess I'll have to wait to investigate some more. Maybe I missed something in the logs.
-
I do not observe shutdown/reboot problems with systemd on two virtual machines, one kdm/KDE and one slim/lxde on a win host. As they got a fresh install of systemd today, did you try to reinstall or dpkg-reconfigure systemd? Is libpam-systemd installed?
Perhaps this one could help to gather logs during late shutdown: https://wiki.frugalware.org/index.php/SystemD#When_shutdown_hangs (https://wiki.frugalware.org/index.php/SystemD#When_shutdown_hangs)
-
I don't know why you work on bugs of that old systemd-44. It is coming a new one soonishly. And as default init system!
-
I don't know why you work on bugs of that old systemd-44. It is coming a new one soonishly. And as default init system!
I'm tired of this now. How do I get rid of systemd and go back "normal boot" while waiting for systemd to get ready and default on siduction?
-
If you set systemd-sysv on hold, then you can simply take it off hold and run a d-u, and then reboot.
-
I don't know why you work on bugs of that old systemd-44. It is coming a new one soonishly. And as default init system!
Isn't there a new version of systemd in experimental? Perhaps try that one
-
@DeepDayze, I would have tried it and told you so ...
My guess, the actual upgrades of sysvinit packages are preconditions of future systemd: They work on a hassel free path for the users. That would explain some minor problems now with old systemd-44
Meanwhile you would like to here L.Poettering talking about the benefits of systemd-journal instead of rsyslog:
https://www.youtube.com/watch?v=i4CACB7paLc
In Short: server management advantages ...
-
If you set systemd-sysv on hold, then you can simply take it off hold and run a d-u, and then reboot.
Done... Thanks dibl
-
Oddly, I have one fully-updated system that does not show the shutdown problem. I will post it here, just for future info:
System: Host: delle6500 Kernel: 3.10-0.towo-siduction-amd64 x86_64 (64 bit)
Desktop: KDE 4.10.5 Distro: siduction 12.1-RC1 Desperado - kde - (201205152133)
Machine: System: Dell product: Latitude E6500
Mobo: Dell model: 0PP476 Bios: Dell version: A14 date: 07/31/2009
CPU: Dual core Intel Core2 Duo CPU P8600 (-MCP-) cache: 3072 KB flags: (lm nx sse sse2 sse3 sse4_1 ssse3 vmx)
Clock Speeds: 1: 2401.00 MHz 2: 2401.00 MHz
Graphics: Card: NVIDIA G98M [Quadro NVS 160M]
X.Org: 1.12.4 drivers: nouveau (unloaded: fbdev,vesa) Resolution: 1920x1200@60.0hz
GLX Renderer: Gallium 0.4 on NV98 GLX Version: 3.0 Mesa 9.1.4
Audio: Card: Intel 82801I (ICH9 Family) HD Audio Controller driver: snd_hda_intel
Sound: Advanced Linux Sound Architecture ver: k3.10-0.towo-siduction-amd64
Network: Card-1: Broadcom BCM4312 802.11b/g LP-PHY driver: b43-pci-bridge
IF: wlan0 state: up mac: 00:23:4e:ab:86:7a
Card-2: Intel 82567LM Gigabit Network Connection driver: e1000e
IF: eth1 state: down mac: 00:21:70:d4:d3:04
Drives: HDD Total Size: 120.0GB (45.4% used) 1: id: /dev/sda model: OCZ_VERTEX size: 120.0GB
Partition: ID: / size: 9.8G used: 9.1G (99%) fs: ext4 ID: swap-1 size: 1.61GB used: 0.00GB (0%) fs: swap
RAID: No RAID devices detected - /proc/mdstat and md_mod kernel raid module present
Sensors: System Temperatures: cpu: 51.5C mobo: N/A gpu: 41.0
Fan Speeds (in rpm): cpu: N/A
Info: Processes: 190 Uptime: 4 min Memory: 851.9/3948.5MB Client: Shell (bash) inxi: 1.9.12
-
Today in experimental systemd-204 arrived.
Someone trying :)
I'll wait 4 days ...
-
runs for about 6 hours ithout problems
greetz
devil
-
On my main productivity system, a big desktop rig with 2 SSDs and 2 hdds, with Nvidia proprietary driver, the new systemd boots to the KDE login in 14 seconds -- very impressive! Shutdown/restart is now working as expected.
-
Today in experimental systemd-204 arrived.
Someone trying :)
I'll wait 4 days ...
ok, I want to give systemd a try again with the new version.
@ ralul, on some post you wrote something about a wrong configured systemd or something like that (in the content about switching to level 3 for doing d-u, if I don't remember wrong).
So whats the right way to install and also maybe configure systemd?
-
@vilde, as I hardly remember this was a long time ago and an issue with sysvinit-compat. Using a newer version and switching to level 3, witch is:
systemctl isolate multi-user.target
should be without problems. But who knows what differentiated compat mechanism will be further developed by Debian maintainers ...
If you want no hassle wait until a new systemd arrives in Debian sid!
On the safe side:
- You can (e)nter the grub line and add: systemd.unit=rescue.target
- You probably are able to boot using the old sysvinit as a last resort.
And pay attention when using:
LVM2 or cryptsetup or a separate /usr partition! Dracut as a mechanism to create an initrd is specially developed to work with systemd. For example openSUSE has had a very efficient distribution specific "mkinitrd" but is now changing to Dracut also. This has reason!!!
As a first step on the way to systemd I would try to boot an extra grub2 entry with a dracut created initrd. At of this moment Debian sid has dracut-027 (which should be fine with systemd-204).
I hope even better will be:
dracut-29
(released upstream - much lvm and cryptsetup work)
systemd-206
(not released upstream - many cgroup changes will finish demanded kernel.org changes. Systemd-205 was half baked in that regard. These cgroup things are important to manage virtual machines on big servers.)
-
So whats the right way to install and also maybe configure systemd?
This is the way I am doing it. If it is incorrect, someone please give further advice.
apt-get -t experimental install systemd libpam-systemd systemd-sysv
echo "systemd-sysv hold" | dpkg --set-selections
Also, note that not all services are necessarily enabled, cleanly. You may have to do something such as:
systemctl.enable ntp
to get a particular service started via systemd.
Tim
-
apt-get -t experimental install systemd libpam-systemd systemd-sysv
That's exactly how I've been installing it -- no problems so far on 6 systems.
echo "systemd-sysv hold" | dpkg --set-selections
You only need to do this once. If you previously installed ver. 44-12 and set it to "hold", installing the new version from experimental will change the installed version of systemd-sysv, but it will not change the dpkg status -- it remains a "hold".
Also, note that not all services are necessarily enabled, cleanly. You may have to do something such as:
systemctl.enable ntp
to get a particular service started via systemd.
Tim
As far as I can see, you can simply
service samba stop
or
service samba start
check it with service samba status
I have not needed to do any special configurations at all, to run samba, vmware, and typical ethernet and wireless networking.
-
@dibl, service is a wrapper that might well point to the actual init system.
systemctl stop Foobar
=
service Foobar stop
systemctl enable Foobar
does activate Foobar for the next startsequence.
It simply symlinks in a target. You can also:
mkdir -p /etc/systemd/system/graphical.target.wants
ln -s /usr/lib/systemd/system/Foobar.service \
/etc/systemd/system/graphical.target.wants
-
Thanks @ralul -- good to know.
Looking forward to the day of a new (future) Debian installation with only systemd, I suppose it will be important to understand this, as the remains of the legacy init system will be gone.
-
experimental systemd-204-1
is just a blind shot without Debian specific adaption, the maintainer himself:
Hardware and udev related:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717405
From: Michael Biebl <biebl>
To: Debian Bug Tracking System <submit>
Subject: 50-udev-default.rules: Fails to tag devices with hwdb meta data
Date: Sat, 20 Jul 2013 14:34:56 +0200
Package: udev
Version: 204-1
Severity: normal
Since we are using the custom 50-udev-default.rules file from the old
udev package, we currently dont properly tag devices with the hwdb meta
data.
The upstream 50-udev-default.rules has
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", IMPORT{builtin}="usb_id", IMPORT{builtin}="hwdb --subsystem=usb"
SUBSYSTEM=="input", ENV{ID_INPUT}=="", IMPORT{builtin}="input_id"
ENV{MODALIAS}!="", IMPORT{builtin}="hwdb --subsystem=$env{SUBSYSTEM}"
We should consider replacing our custom 50-udev-default.rules and
91-permissions.rules with the upstream 50-udev-default.rules file.
If there modifications worth keeping, we should try to get them upstream
or maintain them as a minimal patch.
Initramfs related:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717429
Am 20.07.2013 21:51, schrieb Josh Triplett:
> Package: systemd
> Version: 204-1
> Severity: wishlist
>
> systemd supports running from within the initramfs, and it adds various
> features when doing so, such as timing support, or cleaner support for
> encrypted filesystems. Please consider making use of this.
Most likely the wrong component. As you said, systemd supports being run
from the initramfs. This most likely needs to be integrated into
initramfs-tools directly. I don't think the hooks support in
intramfs-tools is flexible enough that this can be done with a few hooks
provided by systemd.
I understand your wish, but this is not something which can be solved in
the systemd package afaics.
Michael
Michael later answers:
Latest dracut releases have support
/ are designed to run systemd in the initramfs.
If initramfs-tools can be changed to utilize systemd, I honestly don't know.
Journal releated:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717386
From: Michael Stapelberg <stapelberg>
To: Josh Triplett <josh>, 717386@bugs.debian.org, Sven Joachim <svenjoac>
Subject: Re: [Pkg-systemd-maintainers] Bug#717386: systemd-journal group does not exist
Date: Sat, 20 Jul 2013 11:37:43 +0200
Hi,
Josh Triplett <josh> writes:
>> > However, systemd does not create this group.
>>
>> As a result, journalctl doesn't work:
>>
>> ,----
>> | $ journalctl
>> | Hint: You are currently not seeing messages from other users and the system.
>> | Users in the 'systemd-journal' group can see all messages. Pass -q to turn off this notice.
>> | No journal files were opened due to insufficient permissions.
>> `----
I am not sure I buy “journalctl doesn’t work”. It works as intended, you just don’t have the nice feature of being in a special group to get more
read access than you currently have. journalctl per se does work, e.g. as root.
> ...
Thanks for creating a bug report to track this, it was planned from our side to do this (but after the upload). I see three action items here:
1. (bug #717386) Create the systemd-journal group
2. (bug #717388) Ensure systemd-journal and adm have read access to /var/log/journal
3. (bug #717388) Patch the message in journalctl to make users aware of the adm group.
-
I'm doing well with systemd 204-2. It has solved the reboot problem. Journalctl is also working with whatever I throw at it. Just some observations.
journald.conf is at /etc/systemd/journald.conf, not, /etc/systemd/systemd-journald.conf. Maybe this changed in the most recent version?
I'm seeing this during boot:
root@siduction64kdeFX:/home/goineasy9# journalctl -b | grep systemd-modules-load.service
Aug 02 22:35:45 siduction64kdeFX systemd[1]: systemd-modules-load.service: main process exited, code=exited, status=1/FAILURE
Aug 02 22:35:45 siduction64kdeFX systemd[1]: Unit systemd-modules-load.service entered failed state.
Aug 02 22:35:49 siduction64kdeFX systemd[1]: systemd-modules-load.service: main process exited, code=exited, status=1/FAILURE
Aug 02 22:35:49 siduction64kdeFX systemd[1]: Unit systemd-modules-load.service entered failed state.
If you look at /lib/systemd/system/systemd-modules-load.service it looks for /usr/local/lib/modules-load.d, and, theres no such folder. The same goes for /run/modules-load.d. This may be the cause of the boot error, but, I haven't looked into it further.
Anyway, so far so good, only time will tell.
-
/etc/systemd/journald.conf, not, /etc/systemd/systemd-journald.conf. Maybe this changed in the most recent version?
Yes, name change to simplyfy all journal related ...
...
Aug 02 22:35:49 siduction64kdeFX systemd[1]: Unit systemd-modules-load.service entered failed state.
If you look at /lib/systemd/system/systemd-modules-load.service it looks for /usr/local/lib/modules-load.d, and, theres no such folder. The same goes for /run/modules-load.d. This may be the cause of the boot error
No, this shouldn't result in a failed state, as in the service unit it is an OR condition:
ConditionDirectoryNotEmpty=|/lib/modules-load.d
ConditionDirectoryNotEmpty=|/usr/lib/modules-load.d
ConditionDirectoryNotEmpty=|/usr/local/lib/modules-load.d
ConditionDirectoryNotEmpty=|/etc/modules-load.d
ConditionDirectoryNotEmpty=|/run/modules-load.d
Can you verify my assumption by simply creating the missing directories?
Or, you could copy the unit file into
/etc/systemd/system/systemd-modules-load.service
and edit: deleting all lines with directories you don't have. Your personal edited unit should have precedence. (Don't forget to delete this file later on to follow upstream when upgrading)
You then could compare log output:
journalctl -b -1
journalctl -b
By the way, the most kernel modules do have appropriate udev rules nowadays, no moules-load needed any more ....
[edit]Ich habe gerade Systemd-204-2 auf Debian ausprobiert:
journalctl -b -1
geht erst ab systemd-206 - also noch nicht Debian sid
-
I discovered today that systemd does not create the user-writeable /run/shm directory, which init does create.
A bug report (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674755) was filed, but closed with no action -- the maintainer does not consider this to be a bug.
It's only important to know if you were thinking of using /run/shm for something.
-
How far away are systemd, next release?
-
Not sure yet, not too much sincere testing has happened. also we need to be able to fully support it.
greetz
devil
-
however it would be a nice plus and it could have a big echo imho.
i use systemd and i am really happy with it
-
I agree, and one of the reasons siduction exists is to promote new stuff. but you only have a positive echo if it works. If it does not, you do not only damage siduction but also the software you wanted to push forward.
greetz
devil
-
i use systemd and i am really happy with it
+1
6 very different hardware platforms are booting siduction flawlessly with systemd.
-
+1
But in Gentoo forums I lately read a lot of difficulties for people who are using Lvm. After more than a year of heavy trolling against systemd in Gentoo forums: Now there are many who want to run Gnome-3.8, which needs systemd. (I really don't know what is it about, half of Gnome-3 is buggy javascript and the rest has lost all of the features Gnome-2 was able to deliver)
And there might be a lot more corner cases beside Lvm and not yet encountered. For example Xfce4 is largely bound to old consolekit session.
-
I agree, and one of the reasons siduction exists is to promote new stuff. but you only have a positive echo if it works. If it does not, you do not only damage siduction but also the software you wanted to push forward.
greetz
devil
absolute words of wisdom
if i had more skills to give i'd help testing and/or contributing and since i'm not a siduction dev i'll thank you for your work.
that said I have to say that you provide excellent support for (debian's) unreleased software such as KDE or razorqt, it would be too much to support systemd as extra feature for siduction. debian supports systemd quite well right now (imho) for desktop purpose, and it is enough for me...
-
i tried to reinstall console-common and i got this error
Looking for keymap to install:
NONE
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
Failed to issue method call: Unit keymap.sh.service failed to load: No such file or directory. See system logs and 'systemctl status keymap.sh.service' for details.
invoke-rc.d: initscript keymap.sh, action "start" failed.
maybe related to this bug
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677314
things like that may prevent to adopt systemd as default :?
(and magic apt-get -f install can't solve this issue :roll: )
-
@belze, this "keymap.sh" is an old sysV script, probably used with old systemd-044, the new one: systemd-localed.service
monitor it:
systemctl status systemd-localed
informs you:
man 8 systemd-localed.service
man 5 locale.conf
man 1 localectl
-
thanks ralul
-
systemd 204-3 has hit unstable last night.
greetz
devil
-
...and i got xserver upgraded and libaudit0 removed. Yay!
-
Tonights update (to 204-4) wants to remove systemd-sysv, that's when it's off hold. When on hold, it prevents the update, saying it depends on 204-3. Guess I'll have to wait a bit.
-
@GoinEasy9 - Do it just as described in the top post of this thread, except for 204-4
http://forum.siduction.org/index.php?topic=3816
Tim
-
Thanks Tim. I knew I was forgetting something. I should have searched for the "apt-mark hold systemd-sysv" line of devil's. That part I remembered. Thanks again.
-
With Arch linux I am currently using version 207 for systemd
I will have to look at Gentoo to see if that is the same, probably is...
On boot I was seeing
TSC fast boot initailazation failed
That message seems to have gone with ver 207..
What I am seeing though are occasional Shutdown locks. That is a New issue.
Don't know if I am ready to go systemd with Debian yet.
Besides the Fast Boot and Shutdown not much else about it impresses me.
-
207-4 in Fedora, but, it's Lennart's home. I'll have to look and see if 207 is in experimental, and, if so, what state it's in.
-
To all those using systemd: Something interesting just appeared on the fedora-devel mailing list. A corruption problem with systemd-journal and btrfs. I still haven't experimented with btrfs, so, I'm at a loss as to some of the nomenclature. The bugzilla link is interesting also.
https://lists.fedoraproject.org/pipermail/devel/2013-September/189610.html
-
you could also have a look at fedora 20 alpha at http://fedoraproject.org/get-prerelease. It comes without syslog and with systemd journal.
greetz
devil
-
I have fedora 20 installed on one hard disk, but haven't really done anything but update it since its install. I keep it to reference newer changes to systemd, but, it seems fedora 19 is keeping up with systemd versions, so, my main F19 install is sufficient. I used to use it to keep an eye on KDE, but, it seems siduction is doing a better job with that.
BTW - Running f20 without syslog isn't as much fun as reading the discussions that lead up to it.
https://lists.fedoraproject.org/pipermail/devel/2013-July/185329.html
I like systemd-journal. I just have to use it more to get used to it. Using Krusader Root-mode and visiting /var/log is just second nature to me.
As far as the journal/btrfs corruption bug? It's just par for the course. I remember an ext4 data corruption bug that was found and fixed just before ext4 became default. Mixing a new init system with a new feature filled file system is bound to create a few hiccups.
-
Thanks GoinEasy9. I have no need to rebalance my 2-drive BTRFS filesystem, which seems to be doing fine, holding only my data. It looks like the issue may be limited to the case where the OS is on BTRFS -- I can't quite tell. Thanks for posting this -- it is worth keeping an eye on.
-
@dibl - I thought of you when I read the post, that's why I posted it. I figured if anyone would encounter this bug it would be you. At least you would be the one to understand what they were talking about.
When our next release iso's are available, I'm going to try a btrfs install myself. Thanks for breaking it in for me. :lol:
-
As far as I can tell from the BTRFS wiki (https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Multiple_Devices), rebalancing (re-striping the RAID) is only needed when you add or remove a block device to/from a multi-device filesystem. This would be important if you were managing a server full of hard drives and swapping in new drives or removing old drives. If that is true, then the procedure used by the bug reporter does not make sense -- there is no reason to rebalance a single filesystem such as / or /home. However, the command should not cause anything to break, so the bug is technically valid.
I made my BTRFS filesystem across two drives in the first place, and have never added nor removed a drive, so rebalancing has never been needed in my case.
-
I have rebalanced before. When I had a fiasco with systemd/udev and ended up reinstalling Siduction from scratch, I made a mistake and my btrfs filesystem was created as RAID-1 instead of RAID-0. So I converted it to RAID-0 and rebalanced it so the striping would be uniform.
Also, the guy who reported the bug is probably an "official" tester who goes through all types of operations just to make sure they work. That is just my guess, though.
Tim
-
The upgrade of acpid to ver. 2.0.20-1 seems to be a bit problematical for systemd. On several (or all) of my half-dozen systems, I saw a hang of the ugprade at the point where the running acpid service was supposed to be shut down. On all but one system, I was able to resolve it with "dpkg --configure -a". On my Toshiba netbook, I could finish d-u, but the prior package would never be removed, so every d-u pulled in the new version, and then hung up trying to shut off the running service. "apt-get purge" could not remove it, either. This morning I fixed it by taking systemd-sysv off hold, letting sysvinit be installed, rebooting, and running the d-u in init 3. Then I reinstalled systemd-sysv and it's all OK.
This is just FYI if anyone else has the same problem with acpid.
EDIT 29 SEP: To clarify, this fix was necessary on both of my 32-bit installations and none of my 64-bit installations.
-
After new installation I am experimenting with systemd again. Looks promising yet.
However I found that the "at" package is now not installable as it seems to insists on the "real" cron, not the service provided by systemd.
As I need to run specific tasks not regulary but at specified times (i.e. halt the system at 4:00) I would need this service.
There was as "systemd atd.service" mentioned at some loccations but this service seems to be not available yet.
Is there any other solution or a workaround available ?
regards
Reiner
-
you could ask in #debian-systemd on oftc.
greetz
devil
-
Well might not actually been caused by systemd but since I changed to systemd I experience quite a lot system- / x-freezes and even more unclean file-systems on startup which cause quite some work with fscks.
Can also be kernel or xorg (or a mixture of all) related, as there had been some upgrades to those, but I think I experienced those since the newinstallation with the change to systemd some days ago.
The home directory (partition) pretty often now suddenly out of the blue is mounted ro and programs cannot write into their configs and folders and store data down.
Had no similar trouble before. The filesystems on this box are ext4.
regards
Reiner
Edit:
In the syslog I currently found huge amounts of those messagges:
Oct 22 20:12:39 TowerLX kernel: [16314.797846] retire_capture_urb: 33 callbacks suppressed
Oct 22 20:12:45 TowerLX kernel: [16320.793338] retire_capture_urb: 41 callbacks suppressed
Oct 22 20:12:51 TowerLX kernel: [16326.930413] retire_capture_urb: 24 callbacks suppressed
-
Googling is telling me that your error is related to some USB sound device, for example:
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=38&t=15851
I don't see anything about systemd and that kernel message.
I am using ext4 filesystems, as well as one btrfs filesystem, and I have not seen any unusual fsck activity since converting multiple computers to systemd.
-
Hmm, I 'll look into that.
I have a webcam with integrated micro connected via usb only.
Maybe this coudl casus that.
regards
Reiner
-
Well,
after removing that webcam (with integrated micro, handled viausb too) those mass messages had gone and I found only messages from nouveau on both (in the meantime I had a similar machine portesd to systemd) systems. And the freezes went on. >:(
Additionly I found now quite an amount of bad-blocks on my main-box. :'(
So I reinstalled my mainbox completely (no badblocks at all now), removed nouveau and installed the nvidia pro. driver and changed to systemd again. Until now no more freezes. Hope it stays in that way 8)
One thing I found is that systemd not alway copes well yet with boot-splash programs like plymouth. On one box (same mainboard) it works pretty well, but on my main-box I deaktivated it by removing "splash"from the grub command-line.
regards
Reiner
-
I have 1 system using the nouveau driver, and 3 using the nvidia proprietary driver, all booting with systemd, and all working good. (Until one of the 3 blew its LCD panel the other day ... ::) ).
-
hmm, I had those nouveau messagges on both systems and also those strange freezes. On the main-box this was a lot more the case. I will wait and see how it goes and then maybe try to test again nouveau on the second box.
ragards
Reiner
-
Hi, I just registered but I have been Siduction for some months. Other distros that I use on a regular basis are Arch (systemd), LinuxBBQ (which is based on Siduction of course. Some versions have systemd as init), Mint (upstart? I don't know to be honest) and Crunchbang (debian stable, sysV I suppose).
My experience is that Arch with systemd boots fast and closes very fast. LinuxBBQ (siduction+systemd) is also fast, slightly less - perhaps because Debian can't use the newest systemd versions? I use lightweight Windowmanagers, such as Openbox and i3wm. I haven't done scientific comparisons, but it feels like the more systemd, the faster boot and close is.
Stability wise, I can't tell differences. I did have X11 crashes in Arch. I haven't really dived into it, but I suppose this is a conflict of the kernel with my hardware (Lenovo Thinkpad), I doubt that systemd is to blame, but you never know of course.
The concept of systemd appeals to me. Yes, it does look monolithic and non-UNIX like, but to me the explanation of Lennart P. is convincing: the alternative is to have lots of seperate config files. I would welcome some unification, one way to set keyboard, mouse, time, locales etc. I a windowmanager most people like it when there is only one file to edit for settings.... so, why not have one system for init and lots of "householding" (keyboard setting, screen settings etc.) as well? I must admit that most of the technical discussions are WAY over my head, I'm just a simple user :-)
Anyway: keep up the great work, siduction crew !!
-
On a 4-year old netbook with an OCZ Vertex 2 SSD, I get from grub menu to slim login prompt in 14 seconds, and to the LXDE desktop 5 seconds after I enter my password. Desktops with hard drives are a bit slower, of course, but still way faster than with sysv. As a person who never really mastered the Debian init scripts and levels in the first place, systemd seems no more intimidating, and is definitely much faster.
-
I have tried systemd on some different computers and also different hard disks on one computer. My experience is that I gain much more time with systemd and a ssd disk than a non ssd disk. The difference in start time with or without systemd is bigger with ssd than non ssd.