[opensuse] displaying systemd startup order?
Related to my question "How do I make systemd wait for iscsi to start before attempting to mount iscsi-based filesystems?", I've been looking at the systemd startup order. What exactly does "systemctl --order" show - the status quo or what will happen on the next start-up? I'm asking because I've added Requires=remote-fs.target to /usr/lib/systemd/system/apache2.service After a "systemctl --daemon-reload", the start-up sequence did not change as expected. I could be way wrong, but I'm not sure systemd considers iscsi filesystems to be remote? According to "systemctl --order" it will attempt to mount them before iscsi is started :-o -- Per Jessen, Zürich (11.8°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 19/03/14 07:50, Per Jessen escribió:
Related to my question "How do I make systemd wait for iscsi to start before attempting to mount iscsi-based filesystems?", I've been looking at the systemd startup order. What exactly does "systemctl --order" show - the status quo or what will happen on the next start-up?
systemd-analyze --order do you mean I guess.. ? will show in what order the service manager has started units till now, in the *current boot*. Startup is heavily parallelized and dynamic, it cannot tell you in what order the next startup will be. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Cristian Rodríguez wrote:
El 19/03/14 07:50, Per Jessen escribió:
Related to my question "How do I make systemd wait for iscsi to start before attempting to mount iscsi-based filesystems?", I've been looking at the systemd startup order. What exactly does "systemctl --order" show - the status quo or what will happen on the next start-up?
systemd-analyze --order do you mean I guess.. ? will show in what order the service manager has started units till now, in the *current boot*.
Startup is heavily parallelized and dynamic, it cannot tell you in what order the next startup will be.
Is there some way of simulating a startup then? Trying to fix this issue with mount not waiting for iscsi seems like a lot of trial-and-error, and having restart the box all the time. -- Per Jessen, Zürich (9.2°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
В Wed, 19 Mar 2014 11:50:57 +0100 Per Jessen <per@computer.org> пишет:
Related to my question "How do I make systemd wait for iscsi to start before attempting to mount iscsi-based filesystems?", I've been looking at the systemd startup order. What exactly does "systemctl --order" show - the status quo or what will happen on the next start-up?
I'm asking because I've added
Requires=remote-fs.target
to
/usr/lib/systemd/system/apache2.service
After a "systemctl --daemon-reload", the start-up sequence did not change as expected.
Requires is orthogonal to startup order. foo.service Requires bar.service means systemd will attempt to start bar.service when requested to start foo.service. It does *not* mean foo.service will be started after bar.service. Use After/Before to influence relative startup order. Requires is almost always wrong (it is too strong dependency). On 13.1 you can use "systemctl list-dependencies --after|--before foo" to see, after/before which units foo will be started. This also works recursively. E.g. ntpd.service ├─network-remotefs.service ├─system.slice ├─systemd-journald.socket ├─basic.target │ ├─systemd-ask-password-plymouth.path ... ├─network.target │ ├─NetworkManager-wait-online.service │ ├─NetworkManager.service │ └─wpa_supplicant.service ├─nss-lookup.target │ └─network.target │ ├─NetworkManager-wait-online.service ... Not sure if this was already present in 12.3
I could be way wrong, but I'm not sure systemd considers iscsi filesystems to be remote? According to "systemctl --order" it will attempt to mount them before iscsi is started :-o
Well, how should systemd know it is iSCSI in the first place? When /etc/fstab is processed, nothing is yet started and device does not exist so it is not even possible to probe it. That's why you were advised to use _netdev to inform systemd about it. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrey Borzenkov wrote:
В Wed, 19 Mar 2014 11:50:57 +0100 Per Jessen <per@computer.org> пишет:
Related to my question "How do I make systemd wait for iscsi to start before attempting to mount iscsi-based filesystems?", I've been looking at the systemd startup order. What exactly does "systemctl --order" show - the status quo or what will happen on the next start-up?
I'm asking because I've added
Requires=remote-fs.target
to
/usr/lib/systemd/system/apache2.service
After a "systemctl --daemon-reload", the start-up sequence did not change as expected.
Requires is orthogonal to startup order. foo.service Requires bar.service means systemd will attempt to start bar.service when requested to start foo.service. It does *not* mean foo.service will be started after bar.service.
Use After/Before to influence relative startup order. Requires is almost always wrong (it is too strong dependency).
So if I want to indicate: "service A depends service B, do not start A unless B has been started" what should I use?
On 13.1 you can use "systemctl list-dependencies --after|--before foo" to see, after/before which units foo will be started. This also works recursively. E.g. [snip] Not sure if this was already present in 12.3
Nope, doesn't work in 12.3.
I could be way wrong, but I'm not sure systemd considers iscsi filesystems to be remote? According to "systemctl --order" it will attempt to mount them before iscsi is started :-o
Well, how should systemd know it is iSCSI in the first place? When /etc/fstab is processed, nothing is yet started and device does not exist so it is not even possible to probe it.
That's why you were advised to use _netdev to inform systemd about it.
Yes, I've tried the _netdev option, but it doesn't change anything. systemd keeps trying to mount the filesystem before iscsi has logged into to the target and acquired it. This is the crux of the issue. -- Per Jessen, Zürich (9.4°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
В Wed, 19 Mar 2014 20:15:59 +0100 Per Jessen <per@computer.org> пишет:
Andrey Borzenkov wrote:
В Wed, 19 Mar 2014 11:50:57 +0100 Per Jessen <per@computer.org> пишет:
Related to my question "How do I make systemd wait for iscsi to start before attempting to mount iscsi-based filesystems?", I've been looking at the systemd startup order. What exactly does "systemctl --order" show - the status quo or what will happen on the next start-up?
I'm asking because I've added
Requires=remote-fs.target
to
/usr/lib/systemd/system/apache2.service
After a "systemctl --daemon-reload", the start-up sequence did not change as expected.
Requires is orthogonal to startup order. foo.service Requires bar.service means systemd will attempt to start bar.service when requested to start foo.service. It does *not* mean foo.service will be started after bar.service.
Use After/Before to influence relative startup order. Requires is almost always wrong (it is too strong dependency).
So if I want to indicate: "service A depends service B, do not start A unless B has been started" what should I use?
If you really mean what you ask, then A.service should have Requisite=B.service But again - this does not mean that if you call "systemctl start A.servcie B.service", B.service will be started first. To make sure, you need both Requisite=B.service After=B.service This ensures, that a) if startup of both A and B is requested, first B is started and then A b) if startup of A is requested but B is not started, startup of A fails.
I could be way wrong, but I'm not sure systemd considers iscsi filesystems to be remote? According to "systemctl --order" it will attempt to mount them before iscsi is started :-o
Well, how should systemd know it is iSCSI in the first place? When /etc/fstab is processed, nothing is yet started and device does not exist so it is not even possible to probe it.
That's why you were advised to use _netdev to inform systemd about it.
Yes, I've tried the _netdev option, but it doesn't change anything. systemd keeps trying to mount the filesystem before iscsi has logged into to the target and acquired it. This is the crux of the issue.
1. How did it work with sysvinit? In which order scripts were started during startup? What script did mount filesystems on iSCSI targets? 2. Did you try adding X-Systemd-Before as I suggested? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrey Borzenkov wrote:
В Wed, 19 Mar 2014 20:15:59 +0100 Per Jessen <per@computer.org> пишет:
Andrey Borzenkov wrote:
В Wed, 19 Mar 2014 11:50:57 +0100 Per Jessen <per@computer.org> пишет:
So if I want to indicate: "service A depends service B, do not start A unless B has been started" what should I use?
If you really mean what you ask, then
Hehe, well, what I would like is that apache2 doesn't start until the appropriate filesystems have been mounted, for instance. Apache2 doesn't like it when a vhost directory is missing. So I figured "don't start apache2" unless "remote-fs" has been completed.
A.service should have Requisite=B.service
But again - this does not mean that if you call "systemctl start A.servcie B.service", B.service will be started first. To make sure, you need both
Requisite=B.service After=B.service
This ensures, that
a) if startup of both A and B is requested, first B is started and then A b) if startup of A is requested but B is not started, startup of A fails.
That sounds good. Thanks for the explanation. I have to admit, all of these Requires,After,Before,Requisite,Wants,Desires,Yearns-For are not exactly intuitive.
That's why you were advised to use _netdev to inform systemd about it.
Yes, I've tried the _netdev option, but it doesn't change anything. systemd keeps trying to mount the filesystem before iscsi has logged into to the target and acquired it. This is the crux of the issue.
Well, operator error I'm ashamed to admit. I put _netdev in the wrong place in fstab ... I'm now left with getting apache2 to start only once remote-fs is done. -- Per Jessen, Zürich (8.2°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Mar 20, 2014 at 12:21 PM, Per Jessen <per@computer.org> wrote:
That's why you were advised to use _netdev to inform systemd about it.
Yes, I've tried the _netdev option, but it doesn't change anything. systemd keeps trying to mount the filesystem before iscsi has logged into to the target and acquired it. This is the crux of the issue.
Well, operator error I'm ashamed to admit. I put _netdev in the wrong place in fstab ...
Did you need to modify iscsi script? It would be helpful if you explained all steps needed to make it work. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrey Borzenkov wrote:
On Thu, Mar 20, 2014 at 12:21 PM, Per Jessen <per@computer.org> wrote:
That's why you were advised to use _netdev to inform systemd about it.
Yes, I've tried the _netdev option, but it doesn't change anything. systemd keeps trying to mount the filesystem before iscsi has logged into to the target and acquired it. This is the crux of the issue.
Well, operator error I'm ashamed to admit. I put _netdev in the wrong place in fstab ...
Did you need to modify iscsi script? It would be helpful if you explained all steps needed to make it work.
Yes, I added this to /etc/init.d/iscsid # X-Start-Before: remote-fs-pre.target You also mentioned "X-Systemd-Before", I haven't tried that. -- Per Jessen, Zürich (8.9°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
В Thu, 20 Mar 2014 10:00:01 +0100 Per Jessen <per@computer.org> пишет:
Andrey Borzenkov wrote:
On Thu, Mar 20, 2014 at 12:21 PM, Per Jessen <per@computer.org> wrote:
That's why you were advised to use _netdev to inform systemd about it.
Yes, I've tried the _netdev option, but it doesn't change anything. systemd keeps trying to mount the filesystem before iscsi has logged into to the target and acquired it. This is the crux of the issue.
Well, operator error I'm ashamed to admit. I put _netdev in the wrong place in fstab ...
Did you need to modify iscsi script? It would be helpful if you explained all steps needed to make it work.
Yes, I added this to /etc/init.d/iscsid
# X-Start-Before: remote-fs-pre.target
Looks like bug report is in order. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Mar 20, 2014 at 12:21 PM, Per Jessen <per@computer.org> wrote:
So I figured "don't start apache2" unless "remote-fs" has been completed.
Better approach for this is RequiresMountsFor=/srv (or whatever paths your apache needs). This automatically adds correct dependencies for the paths given. Again, not sure whether this was available already in 12.3. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrey Borzenkov wrote:
On Thu, Mar 20, 2014 at 12:21 PM, Per Jessen <per@computer.org> wrote:
So I figured "don't start apache2" unless "remote-fs" has been completed.
Better approach for this is
RequiresMountsFor=/srv
(or whatever paths your apache needs). This automatically adds correct dependencies for the paths given. Again, not sure whether this was available already in 12.3.
Looks like it is - the manpage mentions it, and I got no complaints when I added it. I'll restart the box and see what happens. -- Per Jessen, Zürich (9.2°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
Andrey Borzenkov wrote:
On Thu, Mar 20, 2014 at 12:21 PM, Per Jessen <per@computer.org> wrote:
So I figured "don't start apache2" unless "remote-fs" has been completed.
Better approach for this is
RequiresMountsFor=/srv
(or whatever paths your apache needs). This automatically adds correct dependencies for the paths given. Again, not sure whether this was available already in 12.3.
Looks like it is - the manpage mentions it, and I got no complaints when I added it. I'll restart the box and see what happens.
This seems to have done the trick. I say 'seems' as I have had one dependency failure during a startup, but this may have been related to another change. Thanks for pointing me to "RequiresMountsFor", much appreciated! -- Per Jessen, Zürich (12.8°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 20/03/14 08:10, Per Jessen escribió:
This seems to have done the trick. I say 'seems' as I have had one dependency failure during a startup, but this may have been related to another change. Thanks for pointing me to "RequiresMountsFor", much appreciated!
Hrmmm.. maybe we should really add it to the default unit file..after all the default configuration does indeed requires /srv to be present in order to do anything useful. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (3)
-
Andrey Borzenkov -
Cristian Rodríguez -
Per Jessen