Systemd issue

ares952 · 2012-09-07 05:32:36

Hi, after last upgrade, I decided to start using systemd instead initscripts.
With initscripts, everythink was working fine. After upgrade to systemd I have following questions and problems:
1) is it possible to start /etc/rc.local after all services are started?
2) I have following /etc/rc.local:

#!/bin/bash
#
# /etc/rc.local: Local multi-user startup script.
#

mkdir -p /tmp/downloads
chmod a+rwx /tmp/downloads

quotaon -av

echo "1" > /proc/sys/kernel/sysrq

#pppd call a1m

####/etc/rc.d/atd start

ntpdate cz.pool.ntp.org

cpufreq-set -g ondemand

gpm -m /dev/input/mice -t ps2

echo "Waiting for 10s ...."
sleep 10

#backup virtual server
echo "Making backup of VM servers"
echo "Server02"
cp /home/misko/VirtualBox\ VMs/arch64server/arch64server.vdi /backups/server02/arch64server.vdi
echo "Server03"
cp /home/misko/VirtualBox\ VMs/arch64server03/arch64server03.vdi /backups/server03/arch64server03.vdi
echo "Done"

#start virtual servers
su misko -c "VBoxHeadless -s arch64server &"
su misko -c "VBoxHeadless -s arch64server03 &"

All commands are executed up to the command
echo "Done"
(This command is not already executed).

In rc.local I run two virtual machines, but before that, I am making a backup of them. However, it means, the backup is OK, but the commands to start them are not executed. Why is that? With initscripts, everything was working fine. If I login in console and start /etc/rc.local again, everything is executed.

3) I have an external directory, which is mounted to /media/data-external. With the first startup after upgrade to systemd, the external disk was mounted quite late, so no backup was created in /etc/rc.local (because /backups is symlink to one directory on external disk). Could I expect in future any similar problem like this?

Thank you very much.

lahwaacz · 2012-09-07 07:46:53

I understand that you have still initscripts installed, because it contains /usr/lib/systemd/system/rc-local.service, correct?

1) You can create /etc/systemd/system/rc-local.service with something like

.include /usr/lib/systemd/system/rc-local.service
[Unit]
After=multi-user.target

But this will cause very slow boot up time.

2) I suggest moving all items into separate service files - AFAIK rc.local is not really necessary with systemd and is considered a hack.
'/tmp/downloads' can be created using tmpfiles.d - see tmpfiles.d(5)
'echo "1" > /proc/sys/kernel/sysrq' can be replaced with 'kernel.sysrq = 1' in /etc/sysctl.conf
Backing up should be done automatically as soon as the external drive is mounted - look at https://bbs.archlinux.org/viewtopic.php?id=32639
Look at systemd.timer(5) for delayed start up of services.

3) I think making something in boot process dependent on external drive is not a good idea - systemd is based on massive parallelisation, you should create udev rule to do automatic backup - see 2).

ares952 · 2012-09-07 17:24:25

Thanks a lot.
I am using tmpfiles.d and sysctl.conf now.
A was playing with systemd for whole day.
I completelly transferred to systemd. System startup is quite fast.

About backup: I want to backup after each start of system. External disk is usually connected all the time. If I waited for external disk, and it was not connected, the script would wait too long.
The aim is: backup and start virtual machines. If external disk is not available, then it will not backup (it will in next system startup).
So I can not wait for external disk, because it does not have to be connected and I want to start VM as soon as possible (but after system completely starts).

I created vm.service:

[Unit]
Description=VM Servers
ConditionFileIsExecutable=/etc/+vm/vm
After=display-manager.service netcfg.service

[Service]
Type=oneshot
ExecStart=/etc/+vm/vm
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

It works fine. At the beginning, I was trying to use vm.timer, but the timer did not start at all :-(, so I use vm script, where I wait for 60 seconds.

edit:
Still, I do not know, why the following lines:

echo "Done"

#start virtual servers
su misko -c "VBoxHeadless -s arch64server &"
su misko -c "VBoxHeadless -s arch64server03 &"

from the original rc.local were not executed.

Last edited by ares952 (2012-09-07 17:25:35)

falconindy · 2012-09-07 18:42:05

I'm sure your VBoxHeadless commands were run, then quickly killed by systemd. Make a unit template for it.

[Unit]
Description=VBox Headless Instance

[Service]
ExecStart=/usr/bin/VBoxHeadless -s %i
User=misko

Call it something like /etc/systemd/system/vboxheadless@.service, and then you can run 'systemctl enable vboxheadless@arch64server{,03}.service'

lahwaacz · 2012-09-07 18:57:09

ares952 wrote:

About backup: I want to backup after each start of system. External disk is usually connected all the time. If I waited for external disk, and it was not connected, the script would wait too long.
The aim is: backup and start virtual machines. If external disk is not available, then it will not backup (it will in next system startup).
So I can not wait for external disk, because it does not have to be connected and I want to start VM as soon as possible (but after system completely starts).

Create an entry for the partition on external drive in /etc/fstab with 'noauto,x-systemd.automount' options (also useful for separate /home partition). Then you should be able to run 'cp /home/misko/VirtualBox\ VMs/arch64server/arch64server.vdi /backups/server02/arch64server.vdi' anywhere in the boot up process, file operation should be suspended until the partition is fully mounted.

If your internal hard drive is big enough, you can create temporary backup in it (e.g. /temp-backup/) and when the external drive is connected, temporary backups are moved to the external drive (e.g. mv /temp-backup/* /backups/). But if the external drive is connected most of the time, this is quite useless.

ares952 · 2012-09-08 06:39:26

falconindy:
well, I am not sure, if VBoxHeadless commands were started, because command echo "Done" precedes and there was no output on console from this command.

I think, I can not use this:
"/etc/systemd/system/vboxheadless@.service, and then you can run 'systemctl enable vboxheadless@arch64server{,03}.service' "
because my aim is to wait until internal harddrives have no use (all daemons are started, to increase the performance and to decrease startup time), and those commands will start VM immediately.

lahwaacz:
I already have this entry:
LABEL=data-external /media/data-external ext4 noatime,nofail 0 1
So, it external drive is not available it will not automount.

I am not sure, if I can start VMs and backup later. What about consistency of .vdi drives? I am using ext4. May be, If I used btrfs, I would be able to create snapshot of whole .vdi drive, but performence would decrease? When snapshot is done, and VM writes to .vdi, btrfs will have to make a copy of whole 1,5GB file, and it would reduce performance.

But you inspired me about making backup. Now, I make backup to external drive immediatelly with speed of aprox. 30MB/s, but my internal drives have 100MB/s. So I will make the backup to another internal drive first and I will be able to start VMs sooner.

lahwaacz · 2012-09-08 14:40:14

ares952 wrote:

my aim is to wait until internal harddrives have no use (all daemons are started, to increase the performance and to decrease startup time), and those commands will start VM immediately.

This is what systemd.timer is for. Something like this should do it.

[Unit]
Description=VBox Headless timer

[Timer]
OnBootSec=2m
Unit=vm.service

[Install]
WantedBy=basic.target

p.s.: name it vm.timer and enable it, it will launch vm.service (which should not be enabled) 2 minutes (you might need to adjust) after boot up

ares952 wrote:

I already have this entry:
LABEL=data-external /media/data-external ext4 noatime,nofail 0 1
So, it external drive is not available it will not automount.

You should be able to use 'nofail' along with 'noauto,x-systemd.automount', I think.

ares952 wrote:

I am not sure, if I can start VMs and backup later. What about consistency of .vdi drives? I am using ext4. May be, If I used btrfs, I would be able to create snapshot of whole .vdi drive, but performence would decrease? When snapshot is done, and VM writes to .vdi, btrfs will have to make a copy of whole 1,5GB file, and it would reduce performance.

You're right, first backup and then run VM. The tricky part is to make the launch dependent on backup, and run backup only after boot up. Perhaps VirtualBox has some backup tool?

EDIT:

ares952 wrote:

But you inspired me about making backup. Now, I make backup to external drive immediatelly with speed of aprox. 30MB/s, but my internal drives have 100MB/s. So I will make the backup to another internal drive first and I will be able to start VMs sooner.

I think you internal drive has speed 100MB/s for reading and 100MB/s for writing (maybe a little less), but when reading and writing simultaneously, the speed will be 50MB/s - which is still more than 30MB/s.

Last edited by lahwaacz (2012-09-08 14:45:19)

falconindy · 2012-09-08 16:04:16

lahwaacz wrote:

ares952 wrote:
my aim is to wait until internal harddrives have no use (all daemons are started, to increase the performance and to decrease startup time), and those commands will start VM immediately.
This is what systemd.timer is for. Something like this should do it.

No, this is what ordering dependencies are for. What if the disk doesn't show up in 30s? What if it never shows up? Rely on the mount unit being active, not some arbitrary amount of time.

ares952 · 2012-09-09 05:30:45

Well, after some advice a used this solution:

I created new btrfs partition on internal harddrive. There are both VMs, in extra volume. With cron, I create one snapshot every 6 hours, 1 day, 1 week and 1 month, and the old one is deleted. If external harddrive is mounted, I make a copy of all snapshots on the external harddrive.
I was afraid of performance on btrfs snapshots (because of copy on write), but there is no problem. It looks, that cow is not applied on the whole file, but on parts of file (may be sectors?).

Thanks a lot.

Arch Linux

#1 2012-09-07 05:32:36

Systemd issue

#2 2012-09-07 07:46:53

Re: Systemd issue

#3 2012-09-07 17:24:25

Re: Systemd issue

#4 2012-09-07 18:42:05

Re: Systemd issue

#5 2012-09-07 18:57:09

Re: Systemd issue

#6 2012-09-08 06:39:26

Re: Systemd issue

#7 2012-09-08 14:40:14

Re: Systemd issue

#8 2012-09-08 16:04:16

Re: Systemd issue

#9 2012-09-09 05:30:45

Re: Systemd issue

Board footer