Re: [systemd-devel] Ordering for early initialization services
Hi, My concern was being forward compatible with systemd and you have addressed my concern. Thank you. On Sat, Mar 23, 2013 at 3:55 AM, Lennart Poettering lenn...@poettering.netwrote: On Fri, 08.03.13 14:12, Umut Tezduyar (u...@tezduyar.com) wrote: Hi, What would be the advantage of placing an early boot up script in between local-fs.target/sysinit.target OR in between sysinit.target/basic.target? That's a very good question. This hopefully gives a bit of an explanation: http://www.freedesktop.org/software/systemd/man/bootup.html The difference is not that big actually. Basically, sysinit.target is supposed to be the barrier before which all the OS vendor system initialization stuff is finished. And then basic.target is the barrier before normal user services are started. In between the two we initialize the sockets currently, and only really those. i.e. units that belong to the user, but should run before the actual services are started. I plan to introduce paths.target and timers.target in a similar fashion soonishly. Also, as soon as we have kdbus support in systemd we will do bus name registration the same way. I.e. there will be a new unit type .busname for establishing bus names, and they by default are established between sysinit.target and busnames.target or so. Now, some of systemd's own services aren't entirely consistent between what it puts before sysinit.target and what before basic.target. But this is something we should clean up. But in general the rule is: you should place your early-boot stuff *before sysinit.target*. And your late-boot stuff *after basic.target*. And leave everything in between for .socket, .path, .timer, .busname units. I cannot decide what should be the ordering for some early initialization oneshot services I have in my embedded system. These services makes some simple preparations that were previously in /rcS.d/. Dropped support for /rcS.d/ in systemd was placing these services as After=sysinit.target and WantedBy=sysinit.target (and I am not entirely sure but possibly Before=basic.target). I could place them as systemd did before or I could place them as After=local-fs.target and Before=sysinit.target. Since my embedded system doesn't have login prompt, I don't see the difference between basic.target and sysinit.target other than socket activation. Even then, a service that is socket activated has DefaultDependency=yes (It will start after basic.target). To summarize, where are users encouraged to place their early boot up initialization services (ex: setting up the bandwith on a NIC)? sysinit.target! Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Ordering for early initialization services
On Fri, 08.03.13 14:12, Umut Tezduyar (u...@tezduyar.com) wrote: Hi, What would be the advantage of placing an early boot up script in between local-fs.target/sysinit.target OR in between sysinit.target/basic.target? That's a very good question. This hopefully gives a bit of an explanation: http://www.freedesktop.org/software/systemd/man/bootup.html The difference is not that big actually. Basically, sysinit.target is supposed to be the barrier before which all the OS vendor system initialization stuff is finished. And then basic.target is the barrier before normal user services are started. In between the two we initialize the sockets currently, and only really those. i.e. units that belong to the user, but should run before the actual services are started. I plan to introduce paths.target and timers.target in a similar fashion soonishly. Also, as soon as we have kdbus support in systemd we will do bus name registration the same way. I.e. there will be a new unit type .busname for establishing bus names, and they by default are established between sysinit.target and busnames.target or so. Now, some of systemd's own services aren't entirely consistent between what it puts before sysinit.target and what before basic.target. But this is something we should clean up. But in general the rule is: you should place your early-boot stuff *before sysinit.target*. And your late-boot stuff *after basic.target*. And leave everything in between for .socket, .path, .timer, .busname units. I cannot decide what should be the ordering for some early initialization oneshot services I have in my embedded system. These services makes some simple preparations that were previously in /rcS.d/. Dropped support for /rcS.d/ in systemd was placing these services as After=sysinit.target and WantedBy=sysinit.target (and I am not entirely sure but possibly Before=basic.target). I could place them as systemd did before or I could place them as After=local-fs.target and Before=sysinit.target. Since my embedded system doesn't have login prompt, I don't see the difference between basic.target and sysinit.target other than socket activation. Even then, a service that is socket activated has DefaultDependency=yes (It will start after basic.target). To summarize, where are users encouraged to place their early boot up initialization services (ex: setting up the bandwith on a NIC)? sysinit.target! Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Ordering for early initialization services
Hi, I would like to bring my discussion back. Any help? Thanks On Fri, Mar 8, 2013 at 2:12 PM, Umut Tezduyar u...@tezduyar.com wrote: Hi, What would be the advantage of placing an early boot up script in between local-fs.target/sysinit.target OR in between sysinit.target/basic.target? I cannot decide what should be the ordering for some early initialization oneshot services I have in my embedded system. These services makes some simple preparations that were previously in /rcS.d/. Dropped support for /rcS.d/ in systemd was placing these services as After=sysinit.target and WantedBy=sysinit.target (and I am not entirely sure but possibly Before=basic.target). I could place them as systemd did before or I could place them as After=local-fs.target and Before=sysinit.target. Since my embedded system doesn't have login prompt, I don't see the difference between basic.target and sysinit.target other than socket activation. Even then, a service that is socket activated has DefaultDependency=yes (It will start after basic.target). To summarize, where are users encouraged to place their early boot up initialization services (ex: setting up the bandwith on a NIC)? Thanks ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Ordering for early initialization services
Am 08.03.2013 14:12, schrieb Umut Tezduyar: To summarize, where are users encouraged to place their early boot up initialization services (ex: setting up the bandwith on a NIC)? [root@rh:~]$ systemctl status bandwidth.service bandwidth.service - Traffic-Shaping Loaded: loaded (/etc/systemd/system/bandwidth.service; enabled) Active: active (exited) since Di 2013-03-05 12:38:49 CET; 3 days ago Main PID: 16981 (code=exited, status=0/SUCCESS) CGroup: name=systemd:/system/bandwidth.service Mär 05 12:38:49 rh.thelounge.net systemd[1]: Starting Traffic-Shaping Mär 05 12:38:49 rh.thelounge.net systemd[1]: Started Traffic-Shaping [root@rh:~]$ cat /etc/systemd/system/bandwidth.service [Unit] Description=Traffic-Shaping After=network.service network-bonding.service network-bonding-bridge.service network-wlan-bridge.service [Service] Type=oneshot RemainAfterExit=yes ExecStart=/sbin/tc qdisc add dev eth0 root handle 1: htb default 30 r2q 1000 ExecStartPost=/sbin/tc class add dev eth0 parent 1: classid 1:2 htb rate 1000mbit ExecStartPost=/sbin/tc class add dev eth0 parent 1: classid 1:3 htb rate 90mbit ExecStartPost=/sbin/tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dst 10.0.0.0/24 flowid 1:2 ExecStartPost=/sbin/tc filter add dev eth0 protocol ip parent 1:0 prio 2 u32 match ip dst 0.0.0.0/0 flowid 1:3 ExecStartPost=/sbin/tc qdisc add dev eth1 root handle 1: htb default 30 r2q 1000 ExecStartPost=/sbin/tc class add dev eth1 parent 1: classid 1:2 htb rate 1000mbit ExecStartPost=/sbin/tc class add dev eth1 parent 1: classid 1:3 htb rate 90mbit ExecStartPost=/sbin/tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst 10.0.0.0/24 flowid 1:2 ExecStartPost=/sbin/tc filter add dev eth1 protocol ip parent 1:0 prio 2 u32 match ip dst 0.0.0.0/0 flowid 1:3 ExecStop=/sbin/tc qdisc del dev eth0 root ExecStopPost=/sbin/tc qdisc del dev eth1 root [Install] WantedBy=multi-user.target signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Ordering for early initialization services
Maybe bandwith wasn't the best example :) But my question is still valid. On Fri, Mar 8, 2013 at 2:18 PM, Reindl Harald h.rei...@thelounge.netwrote: Am 08.03.2013 14:12, schrieb Umut Tezduyar: To summarize, where are users encouraged to place their early boot up initialization services (ex: setting up the bandwith on a NIC)? [root@rh:~]$ systemctl status bandwidth.service bandwidth.service - Traffic-Shaping Loaded: loaded (/etc/systemd/system/bandwidth.service; enabled) Active: active (exited) since Di 2013-03-05 12:38:49 CET; 3 days ago Main PID: 16981 (code=exited, status=0/SUCCESS) CGroup: name=systemd:/system/bandwidth.service Mär 05 12:38:49 rh.thelounge.net systemd[1]: Starting Traffic-Shaping Mär 05 12:38:49 rh.thelounge.net systemd[1]: Started Traffic-Shaping [root@rh:~]$ cat /etc/systemd/system/bandwidth.service [Unit] Description=Traffic-Shaping After=network.service network-bonding.service network-bonding-bridge.service network-wlan-bridge.service [Service] Type=oneshot RemainAfterExit=yes ExecStart=/sbin/tc qdisc add dev eth0 root handle 1: htb default 30 r2q 1000 ExecStartPost=/sbin/tc class add dev eth0 parent 1: classid 1:2 htb rate 1000mbit ExecStartPost=/sbin/tc class add dev eth0 parent 1: classid 1:3 htb rate 90mbit ExecStartPost=/sbin/tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dst 10.0.0.0/24 flowid 1:2 ExecStartPost=/sbin/tc filter add dev eth0 protocol ip parent 1:0 prio 2 u32 match ip dst 0.0.0.0/0 flowid 1:3 ExecStartPost=/sbin/tc qdisc add dev eth1 root handle 1: htb default 30 r2q 1000 ExecStartPost=/sbin/tc class add dev eth1 parent 1: classid 1:2 htb rate 1000mbit ExecStartPost=/sbin/tc class add dev eth1 parent 1: classid 1:3 htb rate 90mbit ExecStartPost=/sbin/tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst 10.0.0.0/24 flowid 1:2 ExecStartPost=/sbin/tc filter add dev eth1 protocol ip parent 1:0 prio 2 u32 match ip dst 0.0.0.0/0 flowid 1:3 ExecStop=/sbin/tc qdisc del dev eth0 root ExecStopPost=/sbin/tc qdisc del dev eth1 root [Install] WantedBy=multi-user.target ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
