Re: [systemd-devel] Problem with intermediate target
On Thu, 16.04.15 17:10, Christoph Pleger (christoph.ple...@cs.tu-dortmund.de) wrote: Hello, I wrote: Sounds like you want to create intermediate.target, change default.target to point at it, boot all the way up to intermediate.target, and at that point isolate or start multi-user.target. I chose that solution, because from all possible solutions for the desired boot order, it seems to be the one which is closest to my idea. After setting intermediate.target as default target and defining a service belonging to intermediate.target that switches to graphical.target, I discovered the following (which does not happen when graphical.target is the default target): With the package pidentd installed, which does not bring a .service file, but only an init script that wants to create a directory /var/run/identd, at boot time some error messages appear on the screen that /var is not writable. Obviously, /var is not mounted yet when the script is executed. After booting, this is the content of/run/systemd/generator.late/pidentd.service: # Automatically generated by systemd-sysv-generator [Unit] SourcePath=/etc/init.d/pidentd Description=LSB: setup for pidentd DefaultDependencies=no Before=sysinit.target After=remote-fs.target Are you using a Debian-derived distro? We explicitly dont support early-boot sysv scripts upstream, because they are unworkable. I know that Debian patches support for this back in, but that's on them. Please ask the Debian guys for help with this. Early-boot sysv scripts are something we explicitly removed support for years ago, for a good reason. If your distro supports this anyway, they need to care for it. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Problem with intermediate target
On 18 April 2015 at 09:39, Christoph Pleger christoph.ple...@cs.tu-dortmund.de wrote: Hello, Why does systemd start this service before /var is mounted, though the service should be executed after remote-fs.target, and remote-fs.target comes after local-fs.target? Because remote-fs.target is not part of initial transaction. And why is this different in my intermediate.target than in multi-user.target, though intermediate.target defines exactly the same requirements, orders and conflicts as multi-user.target? Because systemd allows to declare extra dependencies that are not directly part of unit definition. E.g. remote-fs.target has WantedBy=multi-user.target. It is *not* dependencies listed in unit configuration of multi-user.target that make it start remote-fs.target. When initial target is multi-user.target all those reverse dependencies (for lack of better word) are pulled in and are part of initial transaction. With another unit as initial target they are skipped. Ah, I understand, that makes it clear. The auto-generated pident.service file only defines that the service should be executed after remote-fs.target, but it does not require it, and because no other service or target wants or requires remote-fs.target before pidentd.service starts, the filesystems are not yet mounted at that point. But then, I think that the way how systemd translates LSB init scripts should be changed. This is the LSB part of /etc/init.d/pidentd: ### BEGIN INIT INFO # Provides: pidentd-run-dir # Required-Start:$remote_fs # Required-Stop: $remote_fs # Default-Start: S # Default-Stop: # Short-Description: setup for pidentd # Description: create /var/run/ident for pidentd ### END INIT INFO As you can see, it defines remote-fs in Required-Start, not in Should-Start. In my opinion, this should result in an additional Requires=remote-fs.target in pidentd.service. Early boot sysv scripts are also gone in Ubuntu. That is - they are masked by native upstart jobs or systemd units. For this case, why can't you specify RuntimeDirectory=ident to the whichever unit pidentd is? Either directly in the unit, or as a /lib/systemd/system/ident.service.d/rundir.conf or some such. And ditch the sysv init script? -- Regards, Dimitri. Pura Vida! https://clearlinux.org Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Problem with intermediate target
Hello, Why does systemd start this service before /var is mounted, though the service should be executed after remote-fs.target, and remote-fs.target comes after local-fs.target? Because remote-fs.target is not part of initial transaction. And why is this different in my intermediate.target than in multi-user.target, though intermediate.target defines exactly the same requirements, orders and conflicts as multi-user.target? Because systemd allows to declare extra dependencies that are not directly part of unit definition. E.g. remote-fs.target has WantedBy=multi-user.target. It is *not* dependencies listed in unit configuration of multi-user.target that make it start remote-fs.target. When initial target is multi-user.target all those reverse dependencies (for lack of better word) are pulled in and are part of initial transaction. With another unit as initial target they are skipped. Ah, I understand, that makes it clear. The auto-generated pident.service file only defines that the service should be executed after remote-fs.target, but it does not require it, and because no other service or target wants or requires remote-fs.target before pidentd.service starts, the filesystems are not yet mounted at that point. But then, I think that the way how systemd translates LSB init scripts should be changed. This is the LSB part of /etc/init.d/pidentd: ### BEGIN INIT INFO # Provides: pidentd-run-dir # Required-Start:$remote_fs # Required-Stop: $remote_fs # Default-Start: S # Default-Stop: # Short-Description: setup for pidentd # Description: create /var/run/ident for pidentd ### END INIT INFO As you can see, it defines remote-fs in Required-Start, not in Should-Start. In my opinion, this should result in an additional Requires=remote-fs.target in pidentd.service. Regards Christoph ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Problem with intermediate target
В Thu, 16 Apr 2015 17:10:57 +0200 Christoph Pleger christoph.ple...@cs.tu-dortmund.de пишет: Hello, I wrote: Sounds like you want to create intermediate.target, change default.target to point at it, boot all the way up to intermediate.target, and at that point isolate or start multi-user.target. I chose that solution, because from all possible solutions for the desired boot order, it seems to be the one which is closest to my idea. After setting intermediate.target as default target and defining a service belonging to intermediate.target that switches to graphical.target, I discovered the following (which does not happen when graphical.target is the default target): With the package pidentd installed, which does not bring a .service file, but only an init script that wants to create a directory /var/run/identd, at boot time some error messages appear on the screen that /var is not writable. Obviously, /var is not mounted yet when the script is executed. After booting, this is the content of/run/systemd/generator.late/pidentd.service: # Automatically generated by systemd-sysv-generator [Unit] SourcePath=/etc/init.d/pidentd Description=LSB: setup for pidentd DefaultDependencies=no Before=sysinit.target After=remote-fs.target [Service] Type=forking Restart=no TimeoutSec=0 IgnoreSIGPIPE=no KillMode=process GuessMainPID=no RemainAfterExit=yes SysVStartPriority=19 ExecStart=/etc/init.d/pidentd start ExecStop=/etc/init.d/pidentd stop Why does systemd start this service before /var is mounted, though the service should be executed after remote-fs.target, and remote-fs.target comes after local-fs.target? Because remote-fs.target is not part of initial transaction. And why is this different in my intermediate.target than in multi-user.target, though intermediate.target defines exactly the same requirements, orders and conflicts as multi-user.target? Because systemd allows to declare extra dependencies that are not directly part of unit definition. E.g. remote-fs.target has WantedBy=multi-user.target. It is *not* dependencies listed in unit configuration of multi-user.target that make it start remote-fs.target. When initial target is multi-user.target all those reverse dependencies (for lack of better word) are pulled in and are part of initial transaction. With another unit as initial target they are skipped. More strange, when booting is completed, the directory /var/run/identd exists. It seems that the init script is called a second time ... May be. systemctl -p WantedBy -p RequiredBy pidentd.service would answer it. And no, I do not think it is systemd feature :) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Problem with intermediate target
Hello, I wrote: Sounds like you want to create intermediate.target, change default.target to point at it, boot all the way up to intermediate.target, and at that point isolate or start multi-user.target. I chose that solution, because from all possible solutions for the desired boot order, it seems to be the one which is closest to my idea. After setting intermediate.target as default target and defining a service belonging to intermediate.target that switches to graphical.target, I discovered the following (which does not happen when graphical.target is the default target): With the package pidentd installed, which does not bring a .service file, but only an init script that wants to create a directory /var/run/identd, at boot time some error messages appear on the screen that /var is not writable. Obviously, /var is not mounted yet when the script is executed. After booting, this is the content of/run/systemd/generator.late/pidentd.service: # Automatically generated by systemd-sysv-generator [Unit] SourcePath=/etc/init.d/pidentd Description=LSB: setup for pidentd DefaultDependencies=no Before=sysinit.target After=remote-fs.target [Service] Type=forking Restart=no TimeoutSec=0 IgnoreSIGPIPE=no KillMode=process GuessMainPID=no RemainAfterExit=yes SysVStartPriority=19 ExecStart=/etc/init.d/pidentd start ExecStop=/etc/init.d/pidentd stop Why does systemd start this service before /var is mounted, though the service should be executed after remote-fs.target, and remote-fs.target comes after local-fs.target? And why is this different in my intermediate.target than in multi-user.target, though intermediate.target defines exactly the same requirements, orders and conflicts as multi-user.target? More strange, when booting is completed, the directory /var/run/identd exists. It seems that the init script is called a second time ... Regards Christoph ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
