systemd: Yet Another Init Replacement

falconindy · 2011-06-26 18:20:25

This sounds like something different. I can't reproduce on any of my VMs. If you google around, you'll find a way to bind systemctl invocation to kbrequest (ctrl-alt-up). You'll be able to see exactly what jobs are active and what's in queue. Certainly it'd be easy to rule out syslog-ng if its stopped (manually) before you shutdown.

Last edited by falconindy (2011-06-26 18:21:09)

WorMzy · 2011-06-26 19:18:48

Alright, I've got that set up. The next time I get a hang I'll see what it has to say.

Also, I'm going to have a lot of fun with custom key mappings on my VT-only install now.

sidneyk · 2011-06-27 06:13:04

falconindy wrote:

I've put syslog-ng-systemd back in the AUR.

I just switched back to syslog-ng-systemd on both my laptop and desktop and all is working fine.

Viper_Scull · 2011-06-27 20:12:12

So far so good with syslog-ng-systemd

WorMzy · 2011-06-28 12:50:38

I haven't experienced any more hangups, and since nobody else seems to have got any, I'm going to have to assume it was some kind of hardware hiccup which just coincidentally happened after I switched log apps.

falconindy · 2011-06-28 15:02:26

syslog-ng 3.2.4-2 is in [testing] with proper systemd support.

sidneyk · 2011-06-28 17:42:51

I'm posting this here just in case anyone using systemd along with plymouth and Gnome and nVidia drivers. I don't really know why I didn't try this before, but I finally got rid of the little black squares with nVidia driver issue. I am using systemd for my init system now and plymouth only shows a splash screen during bootup now and not on shutdown like before (shutdown happens really quick anyway). I put this line "/bin/plymouth quit" in my /etc/rc.local file and have enabled the rc-local.service. Black squares gone. When I tried to use "/bin/plymouth quit --retain splash", it caused my system to hang and not go on to start gdm. The 'workaround' in the plymouth wiki never worked for me. There may well be other, better ways to accomplish this, but this way works without being too clunky.

[EDIT] Nevermind, mkinitcpio-0.7-1 update today broke plymouth for the time being.
[EDIT] The work around for the above problem was to change 'install' to 'build' and just remove the 'add_device' line. Plymouth now builds properly with mkinitcpio and works fine.

Last edited by sidneyk (2011-07-06 05:45:14)

framas · 2011-06-29 20:00:12

falconindy wrote:

A page or two ago in this thread I pointed out that /media gets mounted with a tmpfs over it. If you want your directories to stop "disappearing", mask the /lib/systemd/systemd/media.mount unit.

I tried this like you described on https://bbs.archlinux.org/viewtopic.php … 56#p948656

# systemctl stop media.mount
# ln -s /dev/null /etc/systemd/system/local-fs.target.wants/media.mount
# kill -1 1

After reboot the overlay was still created again.

So I also masked media.mount in /lib/. media.mount looks now like:

 ls -l  /{lib,etc}/systemd/system/local-fs.target.wants/media.mount                                                                                   
lrwxrwxrwx 1 root root 9 29. Jun 19:24 /etc/systemd/system/local-fs.target.wants/media.mount -> /dev/null                                                                        
lrwxrwxrwx 1 root root 9 29. Jun 20:51 /lib/systemd/system/local-fs.target.wants/media.mount -> /dev/null

So everything seems to be ok at this side. The overlay ist still created each time I boot.
When i do a systemctl dump and look for the media.mount unit I still seem to point to the correct file

-> Unit media.mount:
    Description: Media Directory
    Instance: n/a
    Unit Load State: loaded
    Unit Active State: active
    Inactive Exit Timestamp: Wed, 29 Jun 2011 21:09:57 +0200
    Active Enter Timestamp: Wed, 29 Jun 2011 21:09:57 +0200
    Active Exit Timestamp: n/a
    Inactive Enter Timestamp: n/a
    GC Check Good: yes
    Need Daemon Reload: no
    Name: media.mount
    Fragment Path: /lib/systemd/system/media.mount
    Condition Timestamp: Wed, 29 Jun 2011 21:09:57 +0200
    Condition Result: yes
    Requires: systemd-logger.socket
    Requires: -.mount
    RequiredBy: media-data.mount
    WantedBy: local-fs.target
    Conflicts: umount.target
    Before: local-fs.target
    Before: media-data.mount
    Before: umount.target
    After: systemd-logger.socket
    After: -.mount
    References: local-fs.target
    References: systemd-logger.socket
    References: umount.target
    References: -.mount
    ReferencedBy: local-fs.target
    ReferencedBy: media-data.mount
    StopWhenUnneeded: no
    RefuseManualStart: no
    RefuseManualStop: no
    DefaultDependencies: yes
    OnFailureIsolate: no
    IgnoreOnIsolate: yes
    IgnoreOnSnapshot: no
    ControlGroup: cpu:/system/media.mount
    ControlGroup: name=systemd:/system/media.mount
    Mount State: mounted
    Where: /media
    What: tmpfs
    File System Type: tmpfs
    Options: rw,nosuid,nodev,noexec,relatime,rw,mode=755
    From /etc/fstab: no
    From /proc/self/mountinfo: yes
    From fragment: yes
    DirectoryMode: 0755
    UMask: 0002
    WorkingDirectory: /
    RootDirectory: /
    NonBlocking: no
    PrivateTmp: no
    StandardInput: null
    StandardOutput: kmsg
    StandardError: inherit
    SyslogFacility: daemon
    SyslogLevel: info
    KillMode: control-group
    KillSignal: SIGTERM
    SendSIGKILL: yes

So don't know why this is not working here. I will try the tmpfs method next.

Zom · 2011-06-29 20:13:43

Just a heads up from the mailing list, but seems like newer versions of systemd won't actually start a getty until you switch to it.

Personally, I think this sounds cool, but someone might be confused when the change comes.

henny · 2011-06-29 20:19:28

framas wrote:

falconindy wrote:

A page or two ago in this thread I pointed out that /media gets mounted with a tmpfs over it. If you want your directories to stop "disappearing", mask the /lib/systemd/systemd/media.mount unit.

I tried this like you described on https://bbs.archlinux.org/viewtopic.php … 56#p948656

# systemctl stop media.mount
# ln -s /dev/null /etc/systemd/system/local-fs.target.wants/media.mount
# kill -1 1

After reboot the overlay was still created again.

So I also masked media.mount in /lib/. media.mount looks now like:

 ls -l  /{lib,etc}/systemd/system/local-fs.target.wants/media.mount                                                                                   
lrwxrwxrwx 1 root root 9 29. Jun 19:24 /etc/systemd/system/local-fs.target.wants/media.mount -> /dev/null                                                                        
lrwxrwxrwx 1 root root 9 29. Jun 20:51 /lib/systemd/system/local-fs.target.wants/media.mount -> /dev/null

So everything seems to be ok at this side. The overlay ist still created each time I boot.
When i do a systemctl dump and look for the media.mount unit I still seem to point to the correct file

-> Unit media.mount:
    Description: Media Directory
    Instance: n/a
    Unit Load State: loaded
    Unit Active State: active
    Inactive Exit Timestamp: Wed, 29 Jun 2011 21:09:57 +0200
    Active Enter Timestamp: Wed, 29 Jun 2011 21:09:57 +0200
    Active Exit Timestamp: n/a
    Inactive Enter Timestamp: n/a
    GC Check Good: yes
    Need Daemon Reload: no
    Name: media.mount
    Fragment Path: /lib/systemd/system/media.mount
    Condition Timestamp: Wed, 29 Jun 2011 21:09:57 +0200
    Condition Result: yes
    Requires: systemd-logger.socket
    Requires: -.mount
    RequiredBy: media-data.mount
    WantedBy: local-fs.target
    Conflicts: umount.target
    Before: local-fs.target
    Before: media-data.mount
    Before: umount.target
    After: systemd-logger.socket
    After: -.mount
    References: local-fs.target
    References: systemd-logger.socket
    References: umount.target
    References: -.mount
    ReferencedBy: local-fs.target
    ReferencedBy: media-data.mount
    StopWhenUnneeded: no
    RefuseManualStart: no
    RefuseManualStop: no
    DefaultDependencies: yes
    OnFailureIsolate: no
    IgnoreOnIsolate: yes
    IgnoreOnSnapshot: no
    ControlGroup: cpu:/system/media.mount
    ControlGroup: name=systemd:/system/media.mount
    Mount State: mounted
    Where: /media
    What: tmpfs
    File System Type: tmpfs
    Options: rw,nosuid,nodev,noexec,relatime,rw,mode=755
    From /etc/fstab: no
    From /proc/self/mountinfo: yes
    From fragment: yes
    DirectoryMode: 0755
    UMask: 0002
    WorkingDirectory: /
    RootDirectory: /
    NonBlocking: no
    PrivateTmp: no
    StandardInput: null
    StandardOutput: kmsg
    StandardError: inherit
    SyslogFacility: daemon
    SyslogLevel: info
    KillMode: control-group
    KillSignal: SIGTERM
    SendSIGKILL: yes

So don't know why this is not working here. I will try the tmpfs method next.

It actually stopped working for me either, the symlink is still there but media.mount is started on boot. The tmpfs way works flawless.
I guess it stopped working after upgrading to systemd 29 but i didn't test that.

falconindy · 2011-06-29 21:16:11

Works for me. Had to change the symlink to mask the unit from /etc/systemd/system instead of from the wants dir.

yvonney · 2011-06-30 01:56:42

UPDATE COMMENT: [errors after massive fsck errors all fixed with tons of lost files]
just after grub menu: 1 second flash of 2 lines:
"error: out of partition"
"error: no suitable command found"

after bootup: unable to do much at prompt
"unknown teminal "linux"

during bootup after udev rules loading

"syslog-ng line 7 command not found"

yep. my system crapped out bigtime. Been many season since any issues so looking forward to redo or fix.

So: could anyone tell me what to post from my logs. I see a flashing 2 lines just after grub menu.
Something about tty? dunno quite yet. Truly sorry to appear so slack her, just juggling a lot at the moment
and totally down running from live CD here.

right, so ... I believe it's the updates from today (and i do run all testing as well)systemd-arch-unit
systemd and the systemd-arch-unit from today and earlier.

I rebooted. more fsck fixes and lost files than I've EVER seen. and it boots up though tons messed up.
I should read logs? and post... what?

thanks. all sincerely good fun though. a bit surprised and you know the one. I was just thinking today how
fortune I'd been and how solid all the testing stuff had been with my particular system. hehehe

uhhhh.... broken.

Last edited by yvonney (2011-06-30 02:31:21)

Viper_Scull · 2011-07-04 22:38:59

I'm trying to get rid of rc.conf for good. The only thing i keep is network configuration. What would be the native way of systemd of configuring the network?

Maki · 2011-07-05 00:42:30

Viper_Scull wrote:

I'm trying to get rid of rc.conf for good. The only thing i keep is network configuration. What would be the native way of systemd of configuring the network?

systemd does not configure your network for you, try ifplugd or wicd. and keep rc.conf, don't nuke it and don't delete the daemons line, just disable the arch-units in systemd

lymphatik · 2011-07-05 06:40:29

Maki wrote:

Viper_Scull wrote:
I'm trying to get rid of rc.conf for good. The only thing i keep is network configuration. What would be the native way of systemd of configuring the network?
systemd does not configure your network for you, try ifplugd or wicd. and keep rc.conf, don't nuke it and don't delete the daemons line, just disable the arch-units in systemd

You are actually wrong. This will do the trick of course you will have to change the ip and gateway and interface to suit your need.

[Unit]
Description=Network Connectivity
Before=network.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/sbin/ifconfig eth0 10.1.1.3
ExecStart=/sbin/route add default gw 10.1.1.254
ExecStop=/sbin/ifconfig eth0 down

[Install]
WantedBy=multi-user.target

Last edited by lymphatik (2011-07-05 06:40:54)

sidneyk · 2011-07-05 07:24:59

Viper_Scull wrote:

I'm trying to get rid of rc.conf for good. The only thing i keep is network configuration. What would be the native way of systemd of configuring the network?

If you are using Gnome you can install networkmanager and network-manager-applet and enable the service unit ( sudo systemctl enable NetworkManager.service ) and it works fine with auto configured internet connection. If you need some other thing you can configure networkmanager for it and there are also different plugins available for pppoe vpn, etc. This won't give you a network if you boot into recovery mode (I don't know if one was present under the normal way or not) but will give you a network for Gnome or your tty's, at least a working internet connection. I'm not using rc.conf and haven't for a few weeks now. You have to edit or create and enable the native service units for hostname, locale.conf, vconsole.conf, etc. as outlined in the wiki and you have to enable appropriate service units for any of the daemons you were using in rc.conf. I'm running everyday rc.conf free with systemd and Gnome 3 - Gnome Shell and have even uninstalled the initscripts.

Last edited by sidneyk (2011-07-05 07:26:25)

Viper_Scull · 2011-07-05 15:15:55

sidneyk wrote:

Viper_Scull wrote:
I'm trying to get rid of rc.conf for good. The only thing i keep is network configuration. What would be the native way of systemd of configuring the network?
If you are using Gnome you can install networkmanager and network-manager-applet and enable the service unit ( sudo systemctl enable NetworkManager.service ) and it works fine with auto configured internet connection. If you need some other thing you can configure networkmanager for it and there are also different plugins available for pppoe vpn, etc. This won't give you a network if you boot into recovery mode (I don't know if one was present under the normal way or not) but will give you a network for Gnome or your tty's, at least a working internet connection. I'm not using rc.conf and haven't for a few weeks now. You have to edit or create and enable the native service units for hostname, locale.conf, vconsole.conf, etc. as outlined in the wiki and you have to enable appropriate service units for any of the daemons you were using in rc.conf. I'm running everyday rc.conf free with systemd and Gnome 3 - Gnome Shell and have even uninstalled the initscripts.

I'm using Xfce or Wmfs. The thing is i did not want Networkmanager, wicd or anything like that controlling my network. I was using network.service.

lympathik wrote:

You are actually wrong. This will do the trick of course you will have to change the ip and gateway and interface to suit your need.
[Unit]
Description=Network Connectivity
Before=network.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/sbin/ifconfig eth0 10.1.1.3
ExecStart=/sbin/route add default gw 10.1.1.254
ExecStop=/sbin/ifconfig eth0 down
[Install]
WantedBy=multi-user.target

Thanks. I've modified the service so it could use iproute2 instead of the deprecated nettools. I've also disabled network.service, since it loads rc.conf and try to configure the net from it. I've deleted rc.conf and everything seems to be working just fine.
So this is the service:

[Unit]
Description=Network Connectivity
Before=network.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/sbin/ip link set eth0 up ; /sbin/ip addr add 192.168.1.2/24 dev eth0 ; /sbin/ip route add default via 192.168.1.1
ExecStop=/sbin/ip link set eth0 down

[Install]
WantedBy=multi-user.target

Last edited by Viper_Scull (2011-07-08 12:41:48)

falconindy · 2011-07-05 17:58:35

Multiple ExecStart statements have no guarantee of ordering -- they're all called as fork/exec in parallel. You'd be better off serializing....

ExecStart=ip link set eth0 up ; ip addr add .... ; ip route ...

Note that the space around the semi-colon is important. It needs to be its own 'word'.

Last edited by falconindy (2011-07-05 17:59:01)

Viper_Scull · 2011-07-05 18:30:09

falconindy wrote:

Multiple ExecStart statements have no guarantee of ordering -- they're all called as fork/exec in parallel. You'd be better off serializing....
ExecStart=ip link set eth0 up ; ip addr add .... ; ip route ...
Note that the space around the semi-colon is important. It needs to be its own 'word'.

That's an important point, cause ip route needs the link to be up.

Changed now. Thank you.

Last edited by Viper_Scull (2011-07-05 18:30:35)

el mariachi · 2011-07-05 19:22:07

Disregard this post. There was no problem after all.

Last edited by el mariachi (2011-07-05 22:58:09)

ron9 · 2011-07-06 07:29:39

falconindy wrote:

Multiple ExecStart statements have no guarantee of ordering -- they're all called as fork/exec in parallel. You'd be better off serializing....
ExecStart=ip link set eth0 up ; ip addr add .... ; ip route ....

Is it possible to implement wpasupplicant?

[Unit]
Description=Network Connectivity
Before=network.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=ip link set wlan0 up ; ip addr add 10.252.82.10/24 dev wlan0 ; ip route add default via 10.252.82.1
ExecStop=ip link set wlan0 down
[Install]
WantedBy=multi-user.target.

stefano.facchini · 2011-07-06 07:37:48

falconindy wrote:

systemd 29 tagged. Plymouth users will want to grab units from the sourceball or git as I'm no longer distributing them with the package. Sorry.

Hi,
I installed plymouth-git package from the AUR and followed the instructions on the Wiki page, which gave me a correct splash image during the boot, but not while rebooting or halting. I tried to manually install the systemd service files (plymouth*.service, systemd-ask-for-password-plymouth.*) related to plymouth and enable them, but with no effect. Could you please explain how to use them (and why they are not part of the systemd package!)..
thanks

Maki · 2011-07-06 13:07:28

Ever since i disabled the arch compatibility units bootup hangs at a line that prints something about starting random seeds. here is the bootchart http://ompldr.org/vOWRudA/plot.svg

crabman · 2011-07-06 14:58:30

I noticed that systemd starts the displaymanager even if fsck is running one of its "long" checks. Thats annoying because i cant see fscks progress or skip it. Is there a way to make systemd wait until fsck is done only when its checking the whole disk?

I use comment=systemd.automount for my /home partition in fstab

crabman

lymphatik · 2011-07-06 16:27:09

ron9 wrote:

falconindy wrote:
Multiple ExecStart statements have no guarantee of ordering -- they're all called as fork/exec in parallel. You'd be better off serializing....
ExecStart=ip link set eth0 up ; ip addr add .... ; ip route ....
Is it possible to implement wpasupplicant?
[Unit]
Description=Network Connectivity
Before=network.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=ip link set wlan0 up ; ip addr add 10.252.82.10/24 dev wlan0 ; ip route add default via 10.252.82.1
ExecStop=ip link set wlan0 down
[Install]
WantedBy=multi-user.target.

I do not see why not just add the required command line in Execstart and it should work

Arch Linux

#801 2011-06-26 18:20:25

Re: systemd: Yet Another Init Replacement

#802 2011-06-26 19:18:48

Re: systemd: Yet Another Init Replacement

#803 2011-06-27 06:13:04

Re: systemd: Yet Another Init Replacement

#804 2011-06-27 20:12:12

Re: systemd: Yet Another Init Replacement

#805 2011-06-28 12:50:38

Re: systemd: Yet Another Init Replacement

#806 2011-06-28 15:02:26

Re: systemd: Yet Another Init Replacement

#807 2011-06-28 17:42:51

Re: systemd: Yet Another Init Replacement

#808 2011-06-29 20:00:12

Re: systemd: Yet Another Init Replacement

#809 2011-06-29 20:13:43

Re: systemd: Yet Another Init Replacement

#810 2011-06-29 20:19:28

Re: systemd: Yet Another Init Replacement

#811 2011-06-29 21:16:11

Re: systemd: Yet Another Init Replacement

#812 2011-06-30 01:56:42

Re: systemd: Yet Another Init Replacement

#813 2011-07-04 22:38:59

Re: systemd: Yet Another Init Replacement

#814 2011-07-05 00:42:30

Re: systemd: Yet Another Init Replacement

#815 2011-07-05 06:40:29

Re: systemd: Yet Another Init Replacement

#816 2011-07-05 07:24:59

Re: systemd: Yet Another Init Replacement

#817 2011-07-05 15:15:55

Re: systemd: Yet Another Init Replacement

#818 2011-07-05 17:58:35

Re: systemd: Yet Another Init Replacement

#819 2011-07-05 18:30:09

Re: systemd: Yet Another Init Replacement

#820 2011-07-05 19:22:07

Re: systemd: Yet Another Init Replacement

#821 2011-07-06 07:29:39

Re: systemd: Yet Another Init Replacement

#822 2011-07-06 07:37:48

Re: systemd: Yet Another Init Replacement

#823 2011-07-06 13:07:28

Re: systemd: Yet Another Init Replacement

#824 2011-07-06 14:58:30

Re: systemd: Yet Another Init Replacement

#825 2011-07-06 16:27:09

Re: systemd: Yet Another Init Replacement

Board footer