systemd: Yet Another Init Replacement

vostok4 · 2011-11-17 08:15:19

tomegun wrote:

My guess is that we should look at how dracut deals with this and see if there is anything we could do to make NETWORK_PERSIST obsolete. As far as I know there is no support for anything like NETWORK_PERSIS in fedora, but I might be wrong...

Hm, well I will try to dig around later this week. I might just modify my net unit for now to not shut down. Quite annoying when you cannot/halt the machine unless physically there.

eworm · 2011-11-21 17:07:20

For openvpn I've switched from netcfg to systemd. But I have one problem with systemd: The up script is only run if I give absolute paths. pwd inside the script tells me that the working directory is "/". Why does systemd ignore "WorkingDirectory=/etc/openvpn" from the service file?

Awebb · 2011-11-21 17:55:31

eworm wrote:

For openvpn I've switched from netcfg to systemd.

Why did you? OpenVPN works fine on a "standard Arch" for me. Did I miss anything? Now I'm curious…

Vamp898 · 2011-11-21 17:57:38

There is one thing that still bothers me.

right now Archlinux is run on top of sysvinit, am i right?

But if i think about an typical sysvinit i have the /etc/rc.{0...6}.d with all the scripts and /etc/init.d

Archlinux only uses /etc/rc.d and places all skripts there and those are run by reading the /etc/rc.conf.

so the only thing that is used from sysvinit is the application init itself afaik.

Please correct me if im already wrong.

Now the thing that is mysterious to me. If Archlinux will go to systemd, will Archlinux use systemd as it is desinged to be used or will systemd just replace the init itself and the rest will stay like it is.

To say the truth, i can´t imagine that it could be done more flat and easy like it is now

eworm · 2011-11-21 18:26:08

Awebb wrote:

eworm wrote:
For openvpn I've switched from netcfg to systemd.
Why did you? OpenVPN works fine on a "standard Arch" for me. Did I miss anything? Now I'm curious…

I use systemd for a long time. I used to connect via netcfg but recently switched to wicd for ethernet and wireless lan and to systemd service for openvpn. Not the other way round.

regitator · 2011-11-21 20:20:49

Vamp898 wrote:

There is one thing that still bothers me.
right now Archlinux is run on top of sysvinit, am i right?
But if i think about an typical sysvinit i have the /etc/rc.{0...6}.d with all the scripts and /etc/init.d
Archlinux only uses /etc/rc.d and places all skripts there and those are run by reading the /etc/rc.conf.
so the only thing that is used from sysvinit is the application init itself afaik.
Please correct me if im already wrong.
Now the thing that is mysterious to me. If Archlinux will go to systemd, will Archlinux use systemd as it is desinged to be used or will systemd just replace the init itself and the rest will stay like it is.
To say the truth, i can´t imagine that it could be done more flat and easy like it is now

I'm not sure i understand you correctly and i'm pretty sure i got a lot of misconceptions about the whole init process, but that's my idea of it: atm arch by default relies on sysvinit and is configured by the arch-specific rc.conf. It uses "all" of sysvinit.
By switching to systemd, you have to use "all" of it. That means the rc.conf is ignored and the systemd-config files (non-arch-specific) are used.
The only interconnection between those are some packages specific for Archlinux, that make systemd somewhat compatible with the old configuration. It still uses "all" of systemd however.
The cleaner way is to switch to the new systemd configuration.

Vamp898 · 2011-11-21 20:57:00

The name SysVinit comes afaik from the 5 runlevels.

Archlinux doesnt use them by default.

Also SysVinit is not able to start daemons parallel, archlinux does

so for me it seems like the only thing archlinux uses from SysVinit is the init process itself, the other things are arch-specific.

So indirect Archlinux have a own INIT-System which just uses the init-process from SysVinit.

This is the most simple and just KISS way, how archlinux is and was.

systemd is not KISS in my oppinion in any way. The Daemons seems to be no longer controlled by the rc.conf, you have an completely outstanding standalone init-system with its own tools and so on.

This sounds much less KISS than a single variable in a global configuration file which defines the starting daemons and a skript parses this variable to start the daemons in /etc/rc.conf. In fact this is the most KISS way to do that and it works quite good.

Awebb · 2011-11-21 22:18:20

Vamp898 wrote:

The name SysVinit comes afaik from the 5 runlevels.

I'm too tired for a nifty reply. Sorry. Your afaik must be a black market copy.

http://en.wikipedia.org/wiki/System_V

EDIT: KISS is not a force of nature. If there is a certain complexity, you need a complex tool. Simplicity is relative. Would Sauron think Voldemord is evil?

Last edited by Awebb (2011-11-21 22:20:47)

tomegun · 2011-11-22 07:05:08

Vamp898 wrote:

systemd is not KISS in my oppinion in any way. The Daemons seems to be no longer controlled by the rc.conf, you have an completely outstanding standalone init-system with its own tools and so on.
This sounds much less KISS than a single variable in a global configuration file which defines the starting daemons and a skript parses this variable to start the daemons in /etc/rc.conf. In fact this is the most KISS way to do that and it works quite good.

If our initscripts gave the same features as systemd, then you would of course be right. However, that is far, far from the case. For the features provided by systemd, and from the point of view of the sysadmin / packagers, I think systemd is very KISS indeed. Sure, it has some issues that need to be worked out before it becomes as smooth to use as one would like, but the main principles behind systemd are clearly superior in every way to the traditional sysvinit.

Last edited by tomegun (2011-11-22 07:06:12)

unikum · 2011-11-23 19:40:22

Hi there.

I installed systemd packages and nfs-common not start:

$ systemctl status nfs-common.service
nfs-common.service - NFS Client Daemon
          Loaded: loaded (/lib/systemd/system/nfs-common.service; disabled)
          Active: failed since Thu, 24 Nov 2011 02:27:44 +0700; 14min ago
         Process: 562 ExecStart=/etc/rc.d/nfs-common start (code=exited, status=1/FAILURE)
          CGroup: name=systemd:/system/nfs-common.service

Packages versions:

community/initscripts-systemd v25-1 (systemd)
community/systemd 37-2 (systemd)
community/systemd-arch-units 20111023-1 (systemd)

I tried manual launch nfs daemon

/etc/rc.d/nfs-common start
Start rpcbind first.

$ systemctl status rpcbind.service 
rpcbind.service - RPC Bind
          Loaded: loaded (/lib/systemd/system/rpcbind.service; disabled)
          Active: active (running) since Thu, 24 Nov 2011 02:27:43 +0700; 15min ago
         Process: 495 ExecStart=/usr/bin/rpcbind (code=exited, status=0/SUCCESS)
        Main PID: 496 (rpcbind)
          CGroup: name=systemd:/system/rpcbind.service
                  └ 496 /usr/bin/rpcbind

Last edited by unikum (2011-11-23 19:43:13)

crabman · 2011-11-23 23:21:24

I have a backup scipt that is started via a service file on system startup. When killed, i might have to upload serveral GBs again through a dsl line, so i need to prevent an accidetial shutdown somehow. Is there a (clean) way in systemd to do that?

i tried adding

ExecPre=systemctl mask poweroff.target

and the corresponding ExecPost but kept getting "Failed to issue method call: Access denied" messages.

This is the service file:

[Unit]
Description=backup script

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup

[Install]
WantedBy=graphical.target

Tes-- · 2011-11-29 15:02:38

I'm having some trouble with user sessions. Systemd creates cgroups for every session, but they do not get removed, leaving me with a lot of empty cgroups.

The only thing that gets logged is:

2011-11-29T10:03:38.252889+01:00 nandoe systemd-logind[359]: New session c74 of user nt.
2011-11-29T10:03:38.308875+01:00 nandoe console-kit-daemon[490]: missing action
2011-11-29T11:49:55.859053+01:00 nandoe systemd-logind[359]: Removed session c74.
2011-11-29T11:49:55.943016+01:00 nandoe console-kit-daemon[490]: missing action

So, systemd is attempting at least noticing when I log off, yet systemd-cgls:

├ user
│ ├ root
│ │ ├ c70
│ │ ├ c67
│ │ ├ c25
│ │ ├ c24
│ │ ├ c23
│ │ ├ c22
│ │ ├ c21
│ │ └ c20
│ └ nt
│   ├ c76
│   │ ├ 11719 sshd: nt [priv]
│   │ ├ 11729 sshd: nt@pts/0
│   │ ├ 11730 -bash
│   │ ├ 12626 systemd-cgls
│   │ └ 12627 less
│   ├ c75
│   ├ c74
│   ├ c73

tomegun · 2011-11-29 15:24:45

Tes-- wrote:

I'm having some trouble with user sessions. Systemd creates cgroups for every session, but they do not get removed, leaving me with a lot of empty cgroups.

Fixed in git: http://cgit.freedesktop.org/systemd/com … b1fb0bf652

Tes-- · 2011-11-29 21:13:47

Ah, great, I already looked at the bugtracker, but couldn't find anything.

Haptic · 2011-11-30 22:34:17

For some reason, I can't seem to find anything good on how to use systemd. From what I roughly understand from the wiki, I copy the services I want over to the proper directories as stated by the [Install] tag.

I copied of net-auto-wired.service over and it started working again. However for acpid, I don't understand how it is setup. There is an acpid socket file so I placed that in the sockets directory. The acpid service file didn't have an [install] tag so I assumed it was supposed to be in multi-user and added it in myself. I tried starting it manually, but it says 'Warning: unit files do not carry install information.'

What do I need to do?

Edit: After a reboot, I ran 'systemctl status acpid.service' and apparently its active. Am I correctly utilizing systemd?

Last edited by Haptic (2011-12-01 01:49:29)

falconindy · 2011-12-01 02:21:46

Haptic wrote:

For some reason, I can't seem to find anything good on how to use systemd. From what I roughly understand from the wiki, I copy the services I want over to the proper directories as stated by the [Install] tag.
I copied of net-auto-wired.service over and it started working again. However for acpid, I don't understand how it is setup. There is an acpid socket file so I placed that in the sockets directory. The acpid service file didn't have an [install] tag so I assumed it was supposed to be in multi-user and added it in myself. I tried starting it manually, but it says 'Warning: unit files do not carry install information.'
What do I need to do?
Edit: After a reboot, I ran 'systemctl status acpid.service' and apparently its active. Am I correctly utilizing systemd?

Doesn't sound like it... units with an [Install] section are meant to be activated via systemctl as:

 systemctl enable foo.service

Haptic · 2011-12-01 02:51:26

Let's say I want to enable laptop-mode-tools which has an [Install] tag.

[Unit]
Description=Laptop Power Saving Tools
After=acpid.service
Wants=acpid.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStartPre=/bin/install -d /var/run/laptop-mode-tools ; /bin/touch /var/run/laptop-mode-tools/enabled
ExecStart=/usr/sbin/laptop_mode auto
ExecStop=/usr/sbin/laptop_mode stop
ExecStopPost=/bin/rm -f /var/run/laptop-mode-tools/enabled

[Install]
WantedBy=multi-user.target

Why is it that systemctl will not enable it?

[$] sudo systemctl enable laptop-mode-tools.service 
Failed to issue method call: Invalid argument

ron9 · 2011-12-01 07:59:15

Haptic wrote:

Why is it that systemctl will not enable it?
[$] sudo systemctl enable laptop-mode-tools.service 
Failed to issue method call: Invalid argument

You must reload systemd manager to activate your new settings.

$ systemctl daemon-reload

Kaan · 2011-12-01 11:58:25

When my computer doesn't shutdown properly, like a powerloss, I always get stuck in emergency mode.
I tried adding fsck hook and it seems to be working but it doesn't help. I can't start any targets, systemd immediately goes back into emergency mode without any error.
The only way I know is to boot with sysvinit and then reboot with systemd. Then it works. Any idea why this happens? I use systemd with e4rat bu it is the same without it.

Last edited by Kaan (2011-12-01 12:31:07)

Haptic · 2011-12-02 21:31:06

Assuming you have systemd completely setup, is Arch's original initscripts obsolete?

Also, 'df' outputs 2 entries for my root partition. One named 'rootfs' and other the parition location. Is there a fix around this?

Last edited by Haptic (2011-12-02 21:34:07)

falconindy · 2011-12-03 00:14:39

Haptic wrote:

Assuming you have systemd completely setup, is Arch's original initscripts obsolete?

Right. Arch's initscripts won't be used and they can be installed if you're so inclined.

Haptic wrote:

Also, 'df' outputs 2 entries for my root partition. One named 'rootfs' and other the parition location. Is there a fix around this?

No fix required. Working as intended.

IncredibleLaser · 2011-12-06 16:38:00

I have a strange problem with systemd. Sometimes, when I try to shut down the system from within KDE, shutting down does not complete. It stops with a random service being shut down, and then nothing. When I press Magic SysRq+E, I see udev starting (again), and the system shuts down. Can anyone point me in the direction to look at, e.g. log files? It doesn't happen all the time.

loonyphoenix · 2011-12-06 16:47:30

IncredibleLaser: Try using

/bin/systemctl poweroff

and

/bin/systemctl reboot

as halt and reboot commands respectively in System Settings => Login Screen => Shutdown.

AFAIK in a pure systemd distro like Fedora the default commands should work as they are executed by systemctl anyway, but that can't be done if there are multiple init options available. Arch's /sbin/shutdown and /sbin/reboot are owned by the sysvinit package and therefore can't be provided by the systemd package without conflicting with it.

Last edited by loonyphoenix (2011-12-06 16:57:39)

IncredibleLaser · 2011-12-06 17:00:14

Thanks, I will try this out. Didn't read anything about this in the wiki. I will post if further problems arise.

Edit: OK, it doesn't really solve my problem, but now I was patient enough and waited, and it seems like it is KDM that is taking very long to be stopped. I never had this problem with initscripts, does anybody have an idea?

Edit 2: My problems seem to be KDE related.

Last edited by IncredibleLaser (2011-12-06 18:20:52)

frankieboy · 2011-12-21 08:12:13

Hi!

I have a laptop with a dual boot and lvm setup, systemd works fine there. On
my desktop machine, it stops booting after starting lock (mounting all
partition), I can reboot with ctrl-alt-del (it complains about ck-log-
start.service). The desktop machine has a special disk setup:
ssd dmraid, with /, /boot and /home
raid0 hdd setup with /var and another partition mounted under /home/user
OS is Arch linux latest stable. At boot, systemd stops at fscking /home, /boot and /home/user, but after it gives a recovery console, I can manually mount these partitions, and exiting the recovery console, systemd continues to boot to kdm. I've tried with dmraid.service, dmesg log said the pools are already active, so doesn't need it. I've tried to insert comment=systemd.automount into fstab for /home /boot and /home/user but it didn't help. fstab uses uuids, so device naming change isn't a problem. Using rsyslogd, and common services like
networkmanager, acpid, etc.
With initscripts, it boots fine.
Any help appreciated.

Thx

Ferenc

Arch Linux

#1026 2011-11-17 08:15:19

Re: systemd: Yet Another Init Replacement

#1027 2011-11-21 17:07:20

Re: systemd: Yet Another Init Replacement

#1028 2011-11-21 17:55:31

Re: systemd: Yet Another Init Replacement

#1029 2011-11-21 17:57:38

Re: systemd: Yet Another Init Replacement

#1030 2011-11-21 18:26:08

Re: systemd: Yet Another Init Replacement

#1031 2011-11-21 20:20:49

Re: systemd: Yet Another Init Replacement

#1032 2011-11-21 20:57:00

Re: systemd: Yet Another Init Replacement

#1033 2011-11-21 22:18:20

Re: systemd: Yet Another Init Replacement

#1034 2011-11-22 07:05:08

Re: systemd: Yet Another Init Replacement

#1035 2011-11-23 19:40:22

Re: systemd: Yet Another Init Replacement

#1036 2011-11-23 23:21:24

Re: systemd: Yet Another Init Replacement

#1037 2011-11-29 15:02:38

Re: systemd: Yet Another Init Replacement

#1038 2011-11-29 15:24:45

Re: systemd: Yet Another Init Replacement

#1039 2011-11-29 21:13:47

Re: systemd: Yet Another Init Replacement

#1040 2011-11-30 22:34:17

Re: systemd: Yet Another Init Replacement

#1041 2011-12-01 02:21:46

Re: systemd: Yet Another Init Replacement

#1042 2011-12-01 02:51:26

Re: systemd: Yet Another Init Replacement

#1043 2011-12-01 07:59:15

Re: systemd: Yet Another Init Replacement

#1044 2011-12-01 11:58:25

Re: systemd: Yet Another Init Replacement

#1045 2011-12-02 21:31:06

Re: systemd: Yet Another Init Replacement

#1046 2011-12-03 00:14:39

Re: systemd: Yet Another Init Replacement

#1047 2011-12-06 16:38:00

Re: systemd: Yet Another Init Replacement

#1048 2011-12-06 16:47:30

Re: systemd: Yet Another Init Replacement

#1049 2011-12-06 17:00:14

Re: systemd: Yet Another Init Replacement

#1050 2011-12-21 08:12:13

Re: systemd: Yet Another Init Replacement

Board footer