[systemd-devel] Auto-start of a Service in systemd
Hi All, I'm a newbie in Systemd init system and I'm trying to auto boot/start my service in systemd. But my service gets only enabled and it never runs automatically. I modifying my unit file to depend on sysinit.target and multi-user.target by making use of I used *After=* this also didnt help. *I would like to do something in my unit file from which systemd starts my service automatically after starting it's own system related services. * Can anyone help me regarding this ? My sample service = [Unit] Description=Hey Bings [Service] ExecStart="Run an executable" [Install] WantedBy=multi-user.target *or* sysinit.target -- Regards, Raghavendra. H. R (Raghu) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Auto-start of a Service in systemd
On Wed, Oct 5, 2016 at 12:23 PM, Raghavendra. H. R wrote: > Hi All, > > I'm a newbie in Systemd init system and I'm trying to auto boot/start my > service in systemd. But my service gets only enabled and it never runs > automatically. > > I modifying my unit file to depend on sysinit.target and multi-user.target > by making use of I used After= this also didnt help. > > I would like to do something in my unit file from which systemd starts my > service automatically after starting it's own system related services. > There is no such thing as "own systemd services". All services are equal (but some are more equal than others :) > Can anyone help me regarding this ? > > > My sample service > = > [Unit] > Description=Hey Bings > > [Service] > ExecStart="Run an executable" > > [Install] > WantedBy=multi-user.target or sysinit.target > sysinit.target is wrong, it should never be used for normal service. multi-user.target should work as long as it is your default target (or dependency of default target). You did run "systemctl enable your.service", did not you? What "systemctl status your.service" says? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Auto-start of a Service in systemd
I ran *"systemctl enable test.service" *but when I restart it shows only that the service is only enabled but not active and running. Here is the status of test.service *? test.service - Hey Bings* * Loaded: loaded (/lib/systemd/system/test.service; enabled)* * Active: inactive (dead)* For *WantedBy= *which attribute should be given, whether it is "default.target" or the default target of the system ? Running *systemctl get-default* shows graphical.target as the default target. -- Regards, Raghavendra. H. R (Raghu) On Wed, Oct 5, 2016 at 2:59 PM, Andrei Borzenkov wrote: > On Wed, Oct 5, 2016 at 12:23 PM, Raghavendra. H. R > wrote: > > Hi All, > > > > I'm a newbie in Systemd init system and I'm trying to auto boot/start my > > service in systemd. But my service gets only enabled and it never runs > > automatically. > > > > I modifying my unit file to depend on sysinit.target and > multi-user.target > > by making use of I used After= this also didnt help. > > > > I would like to do something in my unit file from which systemd starts my > > service automatically after starting it's own system related services. > > > > There is no such thing as "own systemd services". All services are > equal (but some are more equal than others :) > > > Can anyone help me regarding this ? > > > > > > My sample service > > = > > [Unit] > > Description=Hey Bings > > > > [Service] > > ExecStart="Run an executable" > > > > [Install] > > WantedBy=multi-user.target or sysinit.target > > > > sysinit.target is wrong, it should never be used for normal service. > multi-user.target should work as long as it is your default target (or > dependency of default target). > > You did run "systemctl enable your.service", did not you? What > "systemctl status your.service" says? > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Auto-start of a Service in systemd
It's working fine now. We should give the default target of the system for *WantedBy= *of the Install section. So I used graphical.target in the Install section and it fixed my issue. Thanks for the information. -- Regards, Raghavendra. H. R (Raghu) On Wed, Oct 5, 2016 at 3:12 PM, Raghavendra. H. R wrote: > I ran *"systemctl enable test.service" *but when I restart it shows only > that the service is only enabled but not active and running. > > Here is the status of test.service > > *? test.service - Hey Bings* > * Loaded: loaded (/lib/systemd/system/test.service; enabled)* > * Active: inactive (dead)* > > > For *WantedBy= *which attribute should be given, whether it is > "default.target" or the default target of the system ? > Running *systemctl get-default* shows graphical.target as the default > target. > > -- > Regards, > > Raghavendra. H. R > (Raghu) > > On Wed, Oct 5, 2016 at 2:59 PM, Andrei Borzenkov > wrote: > >> On Wed, Oct 5, 2016 at 12:23 PM, Raghavendra. H. R >> wrote: >> > Hi All, >> > >> > I'm a newbie in Systemd init system and I'm trying to auto boot/start my >> > service in systemd. But my service gets only enabled and it never runs >> > automatically. >> > >> > I modifying my unit file to depend on sysinit.target and >> multi-user.target >> > by making use of I used After= this also didnt help. >> > >> > I would like to do something in my unit file from which systemd starts >> my >> > service automatically after starting it's own system related services. >> > >> >> There is no such thing as "own systemd services". All services are >> equal (but some are more equal than others :) >> >> > Can anyone help me regarding this ? >> > >> > >> > My sample service >> > = >> > [Unit] >> > Description=Hey Bings >> > >> > [Service] >> > ExecStart="Run an executable" >> > >> > [Install] >> > WantedBy=multi-user.target or sysinit.target >> > >> >> sysinit.target is wrong, it should never be used for normal service. >> multi-user.target should work as long as it is your default target (or >> dependency of default target). >> >> You did run "systemctl enable your.service", did not you? What >> "systemctl status your.service" says? >> > > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] proper way for shutdown script
Hi, the libnss-ldap package on my system used to contain (and still contains) a script that is run on system reboot and shutdown and installs itself into SysV directories for runlevel 0 and 6. However on SystemD I believe these are not run? What would be the proper way to run them? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] proper way for shutdown script
On Wed, 05.10.16 12:47, Xen (l...@xenhideout.nl) wrote: > Hi, > > the libnss-ldap package on my system used to contain (and still contains) a > script that is run on system reboot and shutdown and installs itself into > SysV directories for runlevel 0 and 6. > > However on SystemD I believe these are not run? What would be the proper way > to run them? Why does nss-ldap require something like this? Sounds strange to me... What you probably want to do is write a single unit file with an ExecStart= and an ExecStop= line invoking the right bits to call during boot and those for shutdown. You want to set Type=oneshot and RemainAfterExit=yes. [Unit] Description=Wuffwuffwuff [Service] Type=oneshot RemainAfterExit=yes ExecStart=/usr/bin/my-startup-script ExecStop=/usr/bin/my-shutdown-script [Install] WantedBy=multi-user.target The above should be good enough if your scripts may run during the normal start-up phase and normal shutdown phase, i.e. after all basic initialization of the system (such as device probing, kernel config, and mounting of file systems is done) is completed, in parallel to normal system services. If you however, need this stuff during early boot, i.e. before other regular services are started things get more complicated, as you need DefaultDependencies=no in this case, and declare precisely before and after which other early-boot initiatlization services you want to be started... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Auto-start of a Service in systemd
On Wed, Oct 5, 2016 at 1:19 PM, Raghavendra. H. R wrote: > It's working fine now. We should give the default target of the system for > WantedBy= of the Install section. > So I used graphical.target in the Install section and it fixed my issue. > I doubt it was the reason. grpahical.target pulls in multi-user.target unless you have very customized unit definitions. > Thanks for the information. > > > > -- > Regards, > > Raghavendra. H. R > (Raghu) > > On Wed, Oct 5, 2016 at 3:12 PM, Raghavendra. H. R > wrote: >> >> I ran "systemctl enable test.service" but when I restart it shows only >> that the service is only enabled but not active and running. >> >> Here is the status of test.service >> >> ? test.service - Hey Bings >>Loaded: loaded (/lib/systemd/system/test.service; enabled) >>Active: inactive (dead) >> >> >> For WantedBy= which attribute should be given, whether it is >> "default.target" or the default target of the system ? >> Running systemctl get-default shows graphical.target as the default >> target. >> >> -- >> Regards, >> >> Raghavendra. H. R >> (Raghu) >> >> On Wed, Oct 5, 2016 at 2:59 PM, Andrei Borzenkov >> wrote: >>> >>> On Wed, Oct 5, 2016 at 12:23 PM, Raghavendra. H. R >>> wrote: >>> > Hi All, >>> > >>> > I'm a newbie in Systemd init system and I'm trying to auto boot/start >>> > my >>> > service in systemd. But my service gets only enabled and it never runs >>> > automatically. >>> > >>> > I modifying my unit file to depend on sysinit.target and >>> > multi-user.target >>> > by making use of I used After= this also didnt help. >>> > >>> > I would like to do something in my unit file from which systemd starts >>> > my >>> > service automatically after starting it's own system related services. >>> > >>> >>> There is no such thing as "own systemd services". All services are >>> equal (but some are more equal than others :) >>> >>> > Can anyone help me regarding this ? >>> > >>> > >>> > My sample service >>> > = >>> > [Unit] >>> > Description=Hey Bings >>> > >>> > [Service] >>> > ExecStart="Run an executable" >>> > >>> > [Install] >>> > WantedBy=multi-user.target or sysinit.target >>> > >>> >>> sysinit.target is wrong, it should never be used for normal service. >>> multi-user.target should work as long as it is your default target (or >>> dependency of default target). >>> >>> You did run "systemctl enable your.service", did not you? What >>> "systemctl status your.service" says? >> >> > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Auto-start of a Service in systemd
On Wed, 05.10.16 14:53, Raghavendra. H. R (raghuh...@gmail.com) wrote: > Hi All, > > I'm a newbie in Systemd init system and I'm trying to auto boot/start my > service in systemd. But my service gets only enabled and it never runs > automatically. > > I modifying my unit file to depend on sysinit.target and multi-user.target > by making use of I used *After=* this also didnt help. > > *I would like to do something in my unit file from which systemd starts my > service automatically after starting it's own system related services. * > > Can anyone help me regarding this ? > > > My sample service > = > [Unit] > Description=Hey Bings > > [Service] > ExecStart="Run an executable" > > [Install] > WantedBy=multi-user.target *or* sysinit.target You want to use multi-user.target here. "sysinit.target" is only for special early-boot services. After dropping in this file use "systemctl enable ..." to hook the unit into the boot process for subsequent boots. To also start it immediately, use "systemctl start ...". You may also do both operations in one go by using "systemctl enable --now ...". Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to allow a user to use journalctl to see user-specific systemd service logs?
On Mon, 03.10.16 14:59, Daniel Ng (danieln...@gmail.com) wrote: > I am running user-level services in Ubuntu 16.04 LTS. For example, I have > my test.service located at ~/.config/systemd/user/test.service > > I was able to run the service by doing > > systemctl --user start test.target > > > However, when I try to read its log using journalctl, I got this error > message: > > journalctl --user -u test.service > Hint: You are currently not seeing messages from other users and the > system. > Users in the 'systemd-journal' group can see all messages. Pass -q to > turn off this notice. > No journal files were opened due to insufficient permissions. On very recent systemd versions "journalctl --user -u SERVICENAME" should just work as you think. On older versions you have to use "--user --user-unit=SERVICENAME" instead. > How can I use journalctl for user's specific unit? Also, note that you ned perms to the journal for this to work. If you are root or part of the "systemd-journal" system group, then you are able to see all logs, regardless which subsystem or which user generated them. If you are neither root, nor in that group you will only get to see logs generated by processes you run under your own user ID. However, this only works if the persistent logging is enabled on your system, it does not work if only volatile logging is enabled (check Storage= in journald.conf regarding this). Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Help with boot time debugging
On Tue, 04.10.16 20:55, Manuel Amador (Rudd-O) (rud...@rudd-o.com) wrote: > Hello folks! > > I'm developing a Dracut module and I need to know how to go about > showing what processes run by systemd during boot are saying. This is > for https://github.com/Rudd-O/zfs-fedora-installer . > > For example, I have this one that happens during boot: > > "Starting dracut cmdline hook" > > I want to show on the console what the cmdline hook might have spat to > standard output. I want every single process that produces > stdout/stderr/logging output to show me that output on the console. > > The boot time option systemd.journald.forward_to_console simply did not > work (my console is a ttyS0). Some early-boot services might turn off stdout/stderr being directed to systemd, for some reason. if you want live output I'd suggest using systemd.journald.forward_to_kmsg=1 on the kernel cmdline, and then either peek a the kernel logs via the console or netconsole... For dracut-specific questions it's probably better to contact the Dracut community, and Harald Hoyer, in particular (added to CC) Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-222 mount issues on CentOS 7
On Wed, Oct 05, 2016 at 09:38:18AM +0300, Andrei Borzenkov wrote: > On Wed, Oct 5, 2016 at 8:24 AM, Lokesh Mandvekar > wrote: > > On Tue, Oct 04, 2016 at 10:28:25AM +0200, Michal Sekletar wrote: > >> On Tue, Sep 27, 2016 at 5:05 PM, Lokesh Mandvekar > >> wrote: > >> > Now, I can mount these partitions with: > >> > > >> > # lvm vgchange -ay > >> > > >> > but this still doesn't automount succesfully on a reboot. > >> > > >> > Did I miss something here? > >> > >> I'd check from emergency shell whether lvm2-pvscan@.service was run. > >> This instantiated systemd service is responsible for scaning LVM PVs > >> and auto-activating LVs on them. Note that it is spawned from udev > >> rules in case when certain conditions are met, e.g. block device is > >> identified as LVM2_member and udev event doesn't have SYSTEMD_READY=0 > >> property set. > > > > Michal, thanks for the reply. > > > > What's the correct way to check if lvm2-pvscan@.service was run? > > > > I tried: > > > > # systemctl status lvm2-pvscan@.service > > Failed to get properties: Unit name lvm2-pvscan@.service is not valid. > > > > You need to look for instances of template, not for template itself. > Unfortunately, the only way to do it is really > > systemctl --all | grep lvm2-pvscan Thanks Andrei, I tried this and it returns nothing on my machine. Guess it means none of the instances were run? > > and then check each individual service. > > Extending systemctl to automatically handle (at least, for display > purposes) template instances may be useful. -- Lokesh Freenode: lsm5 GPG: 0xC7C3A0DD https://keybase.io/lsm5 signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Auto-start of a Service in systemd
Andrei, Your doubt is absolutely correct. Default target of the system as nothing to do with auto start of services. I checked both graphical.target & multi-user.target, surprisingly I don't see any big difference in these. Both of the files are almost same except multi-user.target have dependency *After=* with *rescue.service & rescue.target* which is restricting multi-user.target from starting. However graphical.target don't depend on rescue services, so it is active & started. And by making graphical.target as dependency in my unit file solved my problem. Hopefully if I remove the rescue services dependency from multi-user.target and add it as dependency then my service should come up without failures. Thanks for your valuable feedback. Regards, Raghavendra H R -- Regards, Raghavendra. H. R (Raghu) On Wed, Oct 5, 2016 at 4:55 PM, Andrei Borzenkov wrote: > On Wed, Oct 5, 2016 at 1:19 PM, Raghavendra. H. R > wrote: > > It's working fine now. We should give the default target of the system > for > > WantedBy= of the Install section. > > So I used graphical.target in the Install section and it fixed my issue. > > > > I doubt it was the reason. grpahical.target pulls in multi-user.target > unless you have very customized unit definitions. > > > Thanks for the information. > > > > > > > > -- > > Regards, > > > > Raghavendra. H. R > > (Raghu) > > > > On Wed, Oct 5, 2016 at 3:12 PM, Raghavendra. H. R > > wrote: > >> > >> I ran "systemctl enable test.service" but when I restart it shows only > >> that the service is only enabled but not active and running. > >> > >> Here is the status of test.service > >> > >> ? test.service - Hey Bings > >>Loaded: loaded (/lib/systemd/system/test.service; enabled) > >>Active: inactive (dead) > >> > >> > >> For WantedBy= which attribute should be given, whether it is > >> "default.target" or the default target of the system ? > >> Running systemctl get-default shows graphical.target as the default > >> target. > >> > >> -- > >> Regards, > >> > >> Raghavendra. H. R > >> (Raghu) > >> > >> On Wed, Oct 5, 2016 at 2:59 PM, Andrei Borzenkov > >> wrote: > >>> > >>> On Wed, Oct 5, 2016 at 12:23 PM, Raghavendra. H. R < > raghuh...@gmail.com> > >>> wrote: > >>> > Hi All, > >>> > > >>> > I'm a newbie in Systemd init system and I'm trying to auto boot/start > >>> > my > >>> > service in systemd. But my service gets only enabled and it never > runs > >>> > automatically. > >>> > > >>> > I modifying my unit file to depend on sysinit.target and > >>> > multi-user.target > >>> > by making use of I used After= this also didnt help. > >>> > > >>> > I would like to do something in my unit file from which systemd > starts > >>> > my > >>> > service automatically after starting it's own system related > services. > >>> > > >>> > >>> There is no such thing as "own systemd services". All services are > >>> equal (but some are more equal than others :) > >>> > >>> > Can anyone help me regarding this ? > >>> > > >>> > > >>> > My sample service > >>> > = > >>> > [Unit] > >>> > Description=Hey Bings > >>> > > >>> > [Service] > >>> > ExecStart="Run an executable" > >>> > > >>> > [Install] > >>> > WantedBy=multi-user.target or sysinit.target > >>> > > >>> > >>> sysinit.target is wrong, it should never be used for normal service. > >>> multi-user.target should work as long as it is your default target (or > >>> dependency of default target). > >>> > >>> You did run "systemctl enable your.service", did not you? What > >>> "systemctl status your.service" says? > >> > >> > > > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] proper way for shutdown script
Lennart Poettering schreef op 05-10-2016 13:16: Why does nss-ldap require something like this? Sounds strange to me... Thanks man. I was just gonna charge you $40 for missed time... ;-). There are services during startup that are going to hang if you configure nsswitch.conf to also use ldap for e.g. passwd or group. What this means is that in ldap.conf they have enabled something that will refuse ldap lookup for those kinds of users. The script I mentioned adds this to the ldap.conf: nss_initgroups_ignoreusers _apt,avahi,avahi-autoipd,backup,bin,colord,daemon,dnsmasq,games,gnats,hplip,irc,kernoops,list,lp,mail,man,messagebus,news,proxy,pulse,root,rtkit,saned,sddm,sshd,sync,sys,syslog,systemd-bus-proxy,systemd-network,systemd-resolve,systemd-timesync,unscd,usbmux,uucp,uuidd,whoopsie,www-data It does this just based on a numeric ID, so all user IDs and group IDs (presumably) below probably 1000 are getting added there. This is done on shutdown so it works right after installing the package. If you don't do it, the system won't boot and will hang on logind.service even not starting. Raise Network Interfaces will also fail. But currently this is broken because the thing doesn't run by default and you manually have to run /usr/sbin/nssldap-update-ignoreusers but if you install more programs (services) in the meantime, this of course will have to be repeated. So it just does it on every reboot. What you probably want to do is write a single unit file with an ExecStart= and an ExecStop= line invoking the right bits to call during boot and those for shutdown. You want to set Type=oneshot and RemainAfterExit=yes. I spent at least an hour trying to run something that would only run on shutdown and at some point it seemed to work but then I could not reproduce it. I had [Unit] Description=Run script at shutdown and reboot Before=umount.target exit.target DefaultDependencies=no [Service] Type=oneshot ExecStart=/usr/bin/touch /usr/local/testfile.txt [Install] WantedBy=runlevel0.target runlevel6.target But no good [Unit] Description=Wuffwuffwuff [Service] Type=oneshot RemainAfterExit=yes ExecStart=/usr/bin/my-startup-script ExecStop=/usr/bin/my-shutdown-script [Install] WantedBy=multi-user.target I found a solution on Arch forums that would do: [Unit] Description=rawr [Service] Type=oneshot ExecStart=/bin/true ExecStop=/usr/bin/touch /usr/local/somefile.txt RemainAfterExit=yes [Install] WantedBy=sysinit.target And this works. But now the service must be started first before it will be called on shutdown... :-/. Which pollutes the boot-up log and there is really no reason for it? You can still pay the money though, if you want ;-). :p. I started doing this about 2 hours ago and haven't done anything since... anything else, I mean. :-/. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] proper way for shutdown script
Xen schreef op 05-10-2016 14:37: And this works. But now the service must be started first before it will be called on shutdown... :-/. I guess the package installer would have to start the service after installation which would be a solution in that sense, it needs to enable the service anyway. Also I don't understand why /etc/init.d/libnss-ldap masks /etc/systemd/system/libnss-ldap.service for the enable call. It will see the init script and then call the sysv thing and will never get to the actual service file I have created? Thanks for your help. Regards. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] proper way for shutdown script
On Wed, 05.10.16 14:40, Xen (l...@xenhideout.nl) wrote: > Xen schreef op 05-10-2016 14:37: > > >And this works. But now the service must be started first before it > >will be called on shutdown... :-/. > > I guess the package installer would have to start the service after > installation which would be a solution in that sense, it needs to enable the > service anyway. > > Also I don't understand why /etc/init.d/libnss-ldap masks > /etc/systemd/system/libnss-ldap.service for the enable call. That depends on the distro, I guess. At least on Fedora native unit files always take precedence. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] proper way for shutdown script
On Wed, Oct 5, 2016 at 1:47 PM, Xen wrote: > Hi, > > the libnss-ldap package on my system used to contain (and still contains) > a script that is run on system reboot and shutdown and installs itself into > SysV directories for runlevel 0 and 6. > Do you mean libnss-ldapd? The standalone libnss-ldap has been deprecated for quite a while (in favor of nslcd-based thin modules). Also, what does this script do? -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] proper way for shutdown script
On Wed, 05.10.16 14:37, Xen (l...@xenhideout.nl) wrote: > Lennart Poettering schreef op 05-10-2016 13:16: > > >Why does nss-ldap require something like this? Sounds strange to me... > > Thanks man. I was just gonna charge you $40 for missed time... ;-). > > There are services during startup that are going to hang if you configure > nsswitch.conf to also use ldap for e.g. passwd or group. > > What this means is that in ldap.conf they have enabled something that will > refuse ldap lookup for those kinds of users. > > The script I mentioned adds this to the ldap.conf: > > nss_initgroups_ignoreusers > _apt,avahi,avahi-autoipd,backup,bin,colord,daemon,dnsmasq,games,gnats,hplip,irc,kernoops,list,lp,mail,man,messagebus,news,proxy,pulse,root,rtkit,saned,sddm,sshd,sync,sys,syslog,systemd-bus-proxy,systemd-network,systemd-resolve,systemd-timesync,unscd,usbmux,uucp,uuidd,whoopsie,www-data Urgs, what an ugly approach... > I found a solution on Arch forums that would do: > > [Unit] > Description=rawr > > [Service] > Type=oneshot > ExecStart=/bin/true > ExecStop=/usr/bin/touch /usr/local/somefile.txt > RemainAfterExit=yes > > [Install] > WantedBy=sysinit.target > > And this works. But now the service must be started first before it will be > called on shutdown... :-/. > > Which pollutes the boot-up log and there is really no reason for it? It's the way to go on systemd. With current systemd you should be able to leave out the ExecStart=/bin/true bit, if you only care about shutdown? But as I understood you actually wanted to run something both at boot and at shutdown, hence why would you not make use of ExecStart= as well here? Note that the above unit file you posted is a bit contradictory: if you plug something into sysinit.target then your service should be an early-boot service, and those have to have the DefaultDependencies=no setting, as they need to configure their preicse ordering manually, instead of relying on the generic dependencies. hence, either change the Wantedby= setting to WantedBy=multi-user.target and make the service a proper late-boot service, or also set DefaultDEpendencies=no and add the appropriate, manual early-boot dependencies. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-222 mount issues on CentOS 7
On Wed, Oct 5, 2016 at 3:08 PM, Lokesh Mandvekar wrote: > On Wed, Oct 05, 2016 at 09:38:18AM +0300, Andrei Borzenkov wrote: >> On Wed, Oct 5, 2016 at 8:24 AM, Lokesh Mandvekar >> wrote: >> > On Tue, Oct 04, 2016 at 10:28:25AM +0200, Michal Sekletar wrote: >> >> On Tue, Sep 27, 2016 at 5:05 PM, Lokesh Mandvekar >> >> wrote: >> >> > Now, I can mount these partitions with: >> >> > >> >> > # lvm vgchange -ay >> >> > >> >> > but this still doesn't automount succesfully on a reboot. >> >> > >> >> > Did I miss something here? >> >> >> >> I'd check from emergency shell whether lvm2-pvscan@.service was run. >> >> This instantiated systemd service is responsible for scaning LVM PVs >> >> and auto-activating LVs on them. Note that it is spawned from udev >> >> rules in case when certain conditions are met, e.g. block device is >> >> identified as LVM2_member and udev event doesn't have SYSTEMD_READY=0 >> >> property set. >> > >> > Michal, thanks for the reply. >> > >> > What's the correct way to check if lvm2-pvscan@.service was run? >> > >> > I tried: >> > >> > # systemctl status lvm2-pvscan@.service >> > Failed to get properties: Unit name lvm2-pvscan@.service is not valid. >> > >> >> You need to look for instances of template, not for template itself. >> Unfortunately, the only way to do it is really >> >> systemctl --all | grep lvm2-pvscan > > Thanks Andrei, I tried this and it returns nothing on my machine. > Guess it means none of the instances were run? > No, it just means no instance is currently active. This is more or less normal for oneshot units without RemainAfterExit=true flag. So you need to check journal whether any instance of this template has been started. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] bus1, dbus(-daemon) and systemd
On Sat, 01.10.16 13:30, Michael Biebl (mbi...@gmail.com) wrote: > Hi, > > I've been watching the bus1 presentation from this years systemd.conf > (thanks a lot for the video team btw for doing a stellar job). > > What didn't become clear to me i, how bus1, dbus(-daemon) and systemd > are supposed to fit together in the future. > > If I understood David correctly, bus1 is not meant as a drop-in > replacement for dbus-daemon, but rather provide some simpler, lower > level communication primitives. Yeah, bus1 is something very different as I see it. It's not really a successor to D-Bus, and there's no intention to "port" dbus onto bus1 or anything like that. It's more another player in the world of IPC plurality, that's all. > In an earlier talk by Lennart, he mentioned that systemd will > (re)implement dbus-daemon. > Would this reimplmentation be based on bus1 or be a completely > separate re-implementation *not* using bus1? This would be purely a reimplementation of dbus-daemon, and use AF_UNIX hence. > Such a hypothetical dbus-daemon replacement based on bus1, how would > this look like and what would systemd's role be there? I don't think this is going to happen. bus1 is one thing, and dbus another. dbus is going to stay around, but we'll hopefully replace its implementation in dbus-daemon by a newer one. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] bus1, dbus(-daemon) and systemd
Hey On Sat, Oct 1, 2016 at 1:30 PM, Michael Biebl wrote: > Hi, > > I've been watching the bus1 presentation from this years systemd.conf > (thanks a lot for the video team btw for doing a stellar job). > > What didn't become clear to me i, how bus1, dbus(-daemon) and systemd > are supposed to fit together in the future. > > If I understood David correctly, bus1 is not meant as a drop-in > replacement for dbus-daemon, but rather provide some simpler, lower > level communication primitives. Yes! > In an earlier talk by Lennart, he mentioned that systemd will > (re)implement dbus-daemon. > Would this reimplmentation be based on bus1 or be a completely > separate re-implementation *not* using bus1? The idea of re-implementing dbus-daemon with sd-bus (in systemd) is much older than bus1. I don't think we ever discussed it with bus1 in mind. > Such a hypothetical dbus-daemon replacement based on bus1, how would > this look like and what would systemd's role be there? > > I would guess you already thought about that and you already have > plans in that regard. > Would be great if you can share them with us. There are many issues with dbus-daemon. Some can be solved with a simple re-implementation and fixing the known issues, others cannot. The bus1 transport does not magically solve them, either. However, we do have ideas how to make use of bus1 capabilities to allow direct channels between peers, without breaking with dbus semantics. Furthermore, we have discussed subscription-models over match-rules that would even allow to do broadcasts/multicasts without requiring a broker. We are currently doing a reevaluation of our ideas and writing them up. The intention is to get a dbus-daemon drop-in extended with optional bus1 features. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] assign variable to some service item
On Thu, 29.09.16 11:25, Vasiliy Tolstov (v.tols...@selfip.ru) wrote: > I have CPUAffinity inside service file and want to configure it via > EnvironmentFile, but > CPUAffinity=$CPUAffinity does not work with message Failed to parse > CPU affinity '$CPUAffinity' > Environment file contains CPUAffinity="0-2" > Does it possible to assign cpu affinity via env variable ? No, this is not available. Unit file syntax is intentionally kept simple, so that simple tools can parse them without having to implement a macro language. The various ExecXYZ= switches are an exception: you may reference env vars in the specified command lines and they are resolved at the time of invocation. (Well, at least that's the idea. In fact, even though this is the goal a couple of features crept in I think we should better have avoided.) Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] assign variable to some service item
As others have said, this is not possible. It is however possible to configure it via a dropin file. e.g. if your unit is called foo.service, then just mkdir /etc/systemd/system/foo.service.d/ and create a file cpu-affinity.conf inside that folder (any filename will do). In this file put: [Service] CPUAffinity=0-2 Then just reload systemd (systemctl --system reload) and your value should be available. It's not an environment file, but it's still an easy file for administrators to hack on without affecting packaged units in /usr Note, to make life easier for you, you can simply call "systemctl edit foo.service" and an editor will open and let you customise it. HTHs Col Vasiliy Tolstov wrote on 29/09/16 09:25: > I have CPUAffinity inside service file and want to configure it via > EnvironmentFile, but > CPUAffinity=$CPUAffinity does not work with message Failed to parse > CPU affinity '$CPUAffinity' > Environment file contains CPUAffinity="0-2" > Does it possible to assign cpu affinity via env variable ? > Thanks! > > -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] proper way for shutdown script
Lennart Poettering schreef op 05-10-2016 14:52: nss_initgroups_ignoreusers _apt,avahi,avahi-autoipd,backup,bin,colord,daemon,dnsmasq,games,gnats,hplip,irc,kernoops,list,lp,mail,man,messagebus,news,proxy,pulse,root,rtkit,saned,sddm,sshd,sync,sys,syslog,systemd-bus-proxy,systemd-network,systemd-resolve,systemd-timesync,unscd,usbmux,uucp,uuidd,whoopsie,www-data Urgs, what an ugly approach... :). Still better than a non-booting system :p. So apparently this situation has already existed for quite some time. Even worse is that by default the ldap configuration is set to bind-policy = hard, which can also create this issue (a failing LDAP query will then never return, or only return after a long timeout). It's the way to go on systemd. With current systemd you should be able to leave out the ExecStart=/bin/true bit, if you only care about shutdown? But as I understood you actually wanted to run something both at boot and at shutdown, hence why would you not make use of ExecStart= as well here? No that's not true. I only wanted shutdown. If the service never gets started how can it shut down? ExecStop does weird things on services that are oneshot but not RemainAfterStart, at least. Note that the above unit file you posted is a bit contradictory: if you plug something into sysinit.target then your service should be an early-boot service, and those have to have the DefaultDependencies=no setting, as they need to configure their preicse ordering manually, instead of relying on the generic dependencies. I realized that, but it works :p. The reason I picked it like this is because it *seems* that you might have rescue mode situations in which basic.target is never reached, neither is multi-user.target ever reached, but sysinit.target will be reached? Since this is about the system remaining bootable I considered it reason enough to pick it like this :p. hence, either change the Wantedby= setting to WantedBy=multi-user.target and make the service a proper late-boot service, or also set DefaultDEpendencies=no and add the appropriate, manual early-boot dependencies. Ya ya, it was documented also. I read it. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] proper way for shutdown script
Mantas Mikulėnas schreef op 05-10-2016 14:49: On Wed, Oct 5, 2016 at 1:47 PM, Xen wrote: Hi, the libnss-ldap package on my system used to contain (and still contains) a script that is run on system reboot and shutdown and installs itself into SysV directories for runlevel 0 and 6. Do you mean libnss-ldapd? The standalone libnss-ldap has been deprecated for quite a while (in favor of nslcd-based thin modules). Also, what does this script do? Thanks for the hint. I had come across nslcd but it seemed more complicated to get it running the first time, so I opted for the smaller solution having only libnss-ldap. I was not actually aware (anymore) of libnss-ldapd. I am sure it is a "better" solution I was just not sure I could get it running in due time. I also don't know what could be the difference here (I am sure there could be). The script does what I have mentioned in another email which is to exclude certain users and groups from being LDAP-sourced by factual enumeration: the script just lists all of the groups and user (I think) and puts them into the configuration file. It is just a bit of an ugly workaround I guess as to simply checking for user and group ID. The script probably just assumes that all user IDs and user groups start above a certain UID/GID. What you would really need is an LDAP module that would not perform lookups above a certain ID, but this also works, and is in a way more flexible and powerful. Even with very low timeouts LDAP queries would not be okay for system groups. There is just no way you can run a (Linux) system with system groups and users in some LDAP database. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] proper way for shutdown script
On Wed, Oct 5, 2016 at 7:08 PM, Xen wrote: > Mantas Mikulėnas schreef op 05-10-2016 14:49: > >> On Wed, Oct 5, 2016 at 1:47 PM, Xen wrote: >> >> Hi, >>> >>> the libnss-ldap package on my system used to contain (and still >>> contains) a script that is run on system reboot and shutdown and >>> installs itself into SysV directories for runlevel 0 and 6. >>> >> >> Do you mean libnss-ldapd? The standalone libnss-ldap has been >> deprecated for quite a while (in favor of nslcd-based thin modules). >> >> Also, what does this script do? >> > > Thanks for the hint. I had come across nslcd but it seemed more > complicated to get it running the first time, so I opted for the smaller > solution having only libnss-ldap. I was not actually aware (anymore) of > libnss-ldapd. > > I am sure it is a "better" solution I was just not sure I could get it > running in due time. > > I also don't know what could be the difference here (I am sure there could > be). > > The script does what I have mentioned in another email which is to exclude > certain users and groups from being LDAP-sourced by factual enumeration: > the script just lists all of the groups and user (I think) and puts them > into the configuration file. It is just a bit of an ugly workaround I guess > as to simply checking for user and group ID. > > The script probably just assumes that all user IDs and user groups start > above a certain UID/GID. > > What you would really need is an LDAP module that would not perform > lookups above a certain ID, but this also works, and is in a way more > flexible and powerful. > > Even with very low timeouts LDAP queries would not be okay for system > groups. > > There is just no way you can run a (Linux) system with system groups and > users in some LDAP database. > If you mean "would not perform lookups _below_ a certain ID", then sure, that exists. In /etc/nslcd.conf you can specify "nss_min_uid 1000", for example, to avoid lookups for all system UIDs. -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] thoughts on different command structure
Just some considerations I posted elsewhere: - I think there are good reasons to do away with -ctl nomenclature no matter how prevalent these days across Linux systems. - You could call the journalctl tool "journals" -- it doesn't exist, could give access to various system logs, and become the ease-of-use "gateway" to such logs (as it already is, or portends to be). - You could call the systemctl tool "control" -- systemd is now ubiquitoes and important enough on most systems it is installed in that such a generic term would perhaps now be warranted. Instead of the long list of abilities systemctl has now it could be more modularized in the git style of things, or some of its functionality could be extracted to .e.g some "services" tool. Even a tool called just "system" would be up for consideration, I think. Why not think about whether instead of one systemctl there could be perhaps 3 different tools that could be closely related or function as part of modules of their own. Close to that is that many useful programs are called systemd-something which is already that modularisation I speak of. But "systemd" is not a user tool. However you are inclined to type "systemd" after having used on one the other tools. I would propose that systemd would become either the name of the control application (and not just, or not, the daemon) or you think about reorganising the things such that you one one nomenclature for all the different systemd-programs that a person can or needs to use. Having separate commands makes for shell-friendliness (due to tab-completion) but regardless the same is also provided for something like Git. The - nomenclature is very nice though, one frequently wants to write "apt-show" on a debian system. However the systemd-* tools are not most prominent, most prominent are systemctl and journalctl. And personally I just like the upstart syntax as well... If you were responsible for the complete end-user experience of a system, you would choose names as generic as "system" or "control". "system shutdown" is not all that bad of a thing to say. "service enable " would perhaps get rid of the upstart heritage, no matter how much I like it. More I would like "service enable" because it seems more object-oriented, but either way, the current confusion is annoying. How about "target graphical activate" ;-). "journal sys view" "journal openvpn" -- view = default actuion. It becomes a way of selecting objects and performing actions on them. One could even write a systemd-wrapper for nothing other than the syntax of commands. It should be possible to demonstrate a different model that way, but would take a lot of work from a single person not that invested in the product. For example, "service " would default to the "status" command. Or to provide description and status. "target multi-user" would provide a description and possible actions you can perform on that target. "target list" could list all known targets "target history" could show the sequence of targets in the current running system. "target list enabled" would show enabled targets, and so on. So you would turn service and target, two notable concepts, into tools of their own that provide information and manage those two types of objects. Then "journal" becomes the 3rd tool I mentioned. Then "system" becomes the fourth, or something, and you'd be done with that. Then "user" becomes the fifth, making it more possible to access user-specific services (--user). I mean it is all very generic and we know of the complaints against the omnipresence of systemd but at the same time These are all commands for runlevel things and services and startup and shutdown which systemd already is. And log information about that system, in a sense. So you then have these commands: - system - service - target - user - journal They accept a mix of verbs and objects, such that * service action * service list * service status * service overview Become acceptable commands. This does require that some names become forbidden for use as service names. * target action * target history * user change * user logout * user password * user groups * user service <*> * user target <*> * user system <*> * system suspend (...) * system analyze * system mask * system protect network * system shutdown network Become available tools. Broad, system-wide actions or use cases could be given a single, accessible and pleasurable verb that are almost like the equivalent of commands such are "systemctl rescue" today. Why not such actions or targets such as: - closing all network access - closing all external action to services - closing all encrypted containers currently open (by force) - booting a certain user, or shutting down all services belonging to that user. - maybe even entering a maintenance mode that even umounts the root filesystem such that the rootfs can be repaire
Re: [systemd-devel] thoughts on different command structure
On Wed, Oct 05, 2016 at 07:00:11PM +0200, Xen wrote: > [ … renaming propositions … ] Uh, it is way too late for such changes. Maybe if you brought this five years ago… Right now it would only bring pointless differentation between older and newer distributions. We just started unification of all differences in distributions. > > Close to that is that many useful programs are called systemd-something > which is already that modularisation I speak of. > > But "systemd" is not a user tool. However you are inclined to type "systemd" > after having used on one the other tools. Binaries prefixed with systemd- are either not to be started manually (systemd-journald, networkd etc) or not stable/mature enough to be widely used – like cgtop, cgls. The latter kind can be renamed if it matured enough - that what happened with systemd-journalctl → journalctl. As for /usr/libexec/systemd/systemd … well, maybe it should be called systemd-initd from the start. Now it's too late. -- Tomasz TorczThere exists no separation between gods and men: xmpp: zdzich...@chrome.pl one blends softly casual into the other. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] proper way for shutdown script
Mantas Mikulėnas schreef op 05-10-2016 18:34: If you mean "would not perform lookups _below_ a certain ID", then sure, that exists. In /etc/nslcd.conf you can specify "nss_min_uid 1000", for example, to avoid lookups for all system UIDs. Thank you. It seems interesting. I just think that they created the exactly bad design. libnss_ldap and nscd (or unscd) already provides most of the benefits that the author is decribing on his homepage. The caching daemon (nscd) already provided (in all likelyhood) the abstraction that was needed to keep the system functional while also allowing direct connections from programs. Now he has put everything into one package, but the (debian) maintainers have split it into 3 parts. As a better reflection of what it is. He's created (Arthur de Jong, apparently a TU Delft computer science grad) two modules that apparently aggregate requests by sending them to the daemon, who aggregates it and sends it to the LDAP server over a single connection. That seems helpful but the daemon is now the gatekeeper. It's also a caching daemon that you can't turn off. Or at least, maybe it doesn't cache but you still cannot turn it off. I had previously run into problems when nscd propagated names from UID lookups and then used those names from the cache (without qualification) when name lookups were being done, which created problems for users that were named identically on LDAP as on local. Then unscd solved that problem by not doing that :p. The problem was that name lookups would first start with "compat" and only then do "ldap" but this means that local names (that exist) would *never* cause ldap lookups to happen. However, any required for an UID that was found with a name that was also in the local database *would* propagate the name to the name cache. Since unscd didn't do that, suddenly no more problems :p. And since I cannot know in advance whether it will do that... and if it does do that, I'm screwed instantly. "Note that if the LDAP server is unavailable during start-up nslcd will not start." Another problem. My LDAP server on some systems will only be available after VPN connect. Normally this would be at system boot but you can imagine also wifi-connected systems that don't have internet straight away. "Alternatively, the value ALLLOCAL may be used. With that value nslcd builds a full list of non-LDAP users on startup." This is the answer to the behaviour that I started this thread with. This means nss_ldapd doesn't need that script because it does it itself (nslcd does it itself). I guess that could be a superior solution if done right... As an upside nslcd contains a nested group feature that I very much would like to have. So I think that for my own system I am going to use it after all :). Or at least give it a shot. If you mean "would not perform lookups _below_ a certain ID", then sure, that exists. In /etc/nslcd.conf you can specify "nss_min_uid 1000", for example, to avoid lookups for all system UIDs. Actually it still uses nss_initgroups_ignoreusers for that, as said, but now allows a parameter that will do it on startup. I just think the design is bad... - it caches entries, but only for LDAP, and hence doesn't have a lot of caching abilities - it is the gatekeeper for all LDAP queries and everything is channeled through it, making it a point of failure (single point of failure). - nscd / unscd already ensured that 90% of the design imperative of this program was already being catered to - the only thing that remains as a reason is ease of maintenance. And in this case (a library) causing programs to be connecting on their own just seems superior. Instead of having... ;-) a middle man. But that's just me. Any case, thank you for your answer, this helped me in any case to know how libnss_ldapd would be different in this regard. (Of course there is no ldapd, the d is in nslcd) (it would more properly be called libnss_ldapc or something). ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] thoughts on different command structure
Tomasz Torcz schreef op 05-10-2016 19:12: On Wed, Oct 05, 2016 at 07:00:11PM +0200, Xen wrote: [ … renaming propositions … ] Uh, it is way too late for such changes. Maybe if you brought this five years ago… Right now it would only bring pointless differentation between older and newer distributions. We just started unification of all differences in distributions. Well then create a SystemD 2 and make it the next incarnation :p. The idea that it can be "too late" to change anything about anything must surely be seen as a rather weird thing because it would imply that a 1000 years from now we would still be using the same systemd unless it was replaced by some other tool for precisely the reason that it didn't evolve anymore ;-). Alright so I will just create systemQ that does nothing other than translate all of the systemd calls for fun since no one else uses these command names anyway ;-). It will just be impossible to create new or matching functionality ;-). Binaries prefixed with systemd- are either not to be started manually (systemd-journald, networkd etc) or not stable/mature enough to be widely used – like cgtop, cgls. The latter kind can be renamed if it matured enough - that what happened with systemd-journalctl → journalctl. Yes actually I only referred to systemd-analyze. As for /usr/libexec/systemd/systemd … well, maybe it should be called systemd-initd from the start. Now it's too late. It says it is called "init" anyway. It is still started as /sbin/init. $ ps 1 PID TTY STAT TIME COMMAND 1 ?Ss 0:04 /sbin/init $ ps -o comm 1 COMMAND systemd Actually on my system it is symlinked to /bin/systemd I don't really know what for. Probably only to put it in the path? But anyway I don't see how it could ever be too late. Your /usr/libexec/systemd/systemd is my /lib/systemd/systemd. And pretty much nothing needs to know about that path. But anyway. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] thoughts on different command structure
Reindl Harald schreef op 05-10-2016 21:33: Am 05.10.2016 um 21:26 schrieb Xen: Tomasz Torcz schreef op 05-10-2016 19:12: On Wed, Oct 05, 2016 at 07:00:11PM +0200, Xen wrote: [ … renaming propositions … ] Uh, it is way too late for such changes. Maybe if you brought this five years ago… Right now it would only bring pointless differentation between older and newer distributions. We just started unification of all differences in distributions. Well then create a SystemD 2 and make it the next incarnation :p. The idea that it can be "too late" to change anything about anything must surely be seen as a rather weird thing because it would imply that a 1000 years from now we would still be using the same systemd unless it was replaced by some other tool for precisely the reason that it didn't evolve anymore ;-) you sound like we did not have enough "change for the sake of change" in the past 6 years.. realize that the gain of changes needs to *really* outweight the costs all over the world and not just for you Well Reindle I was not expecting a positive reply but I need to pee. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] thoughts on different command structure
Am 05.10.2016 um 21:26 schrieb Xen: Tomasz Torcz schreef op 05-10-2016 19:12: On Wed, Oct 05, 2016 at 07:00:11PM +0200, Xen wrote: [ … renaming propositions … ] Uh, it is way too late for such changes. Maybe if you brought this five years ago… Right now it would only bring pointless differentation between older and newer distributions. We just started unification of all differences in distributions. Well then create a SystemD 2 and make it the next incarnation :p. The idea that it can be "too late" to change anything about anything must surely be seen as a rather weird thing because it would imply that a 1000 years from now we would still be using the same systemd unless it was replaced by some other tool for precisely the reason that it didn't evolve anymore ;-) you sound like we did not have enough "change for the sake of change" in the past 6 years.. realize that the gain of changes needs to *really* outweight the costs all over the world and not just for you ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] thoughts on different command structure
Am 05.10.2016 um 21:42 schrieb Xen: Reindl Harald schreef op 05-10-2016 21:33: Am 05.10.2016 um 21:26 schrieb Xen: Tomasz Torcz schreef op 05-10-2016 19:12: On Wed, Oct 05, 2016 at 07:00:11PM +0200, Xen wrote: [ … renaming propositions … ] Uh, it is way too late for such changes. Maybe if you brought this five years ago… Right now it would only bring pointless differentation between older and newer distributions. We just started unification of all differences in distributions. Well then create a SystemD 2 and make it the next incarnation :p. The idea that it can be "too late" to change anything about anything must surely be seen as a rather weird thing because it would imply that a 1000 years from now we would still be using the same systemd unless it was replaced by some other tool for precisely the reason that it didn't evolve anymore ;-) you sound like we did not have enough "change for the sake of change" in the past 6 years.. realize that the gain of changes needs to *really* outweight the costs all over the world and not just for you Well Reindle I was not expecting a positive reply but I need to pee as long as your are not able to distinct between firstname and lastname or at least quote the last name correctly: well, go pee, it's more productive than ideas change anything for no reason to bomb us (us is endusers and sysadmins) back some years (in fact after RHEL7 has systemd more than a decade) in context of consolidation for no gain ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] thoughts on different command structure
Reindl Harald schreef op 05-10-2016 21:50: Am 05.10.2016 um 21:42 schrieb Xen: Reindl Harald schreef op 05-10-2016 21:33: Am 05.10.2016 um 21:26 schrieb Xen: Tomasz Torcz schreef op 05-10-2016 19:12: On Wed, Oct 05, 2016 at 07:00:11PM +0200, Xen wrote: [ … renaming propositions … ] Uh, it is way too late for such changes. Maybe if you brought this five years ago… Right now it would only bring pointless differentation between older and newer distributions. We just started unification of all differences in distributions. Well then create a SystemD 2 and make it the next incarnation :p. The idea that it can be "too late" to change anything about anything must surely be seen as a rather weird thing because it would imply that a 1000 years from now we would still be using the same systemd unless it was replaced by some other tool for precisely the reason that it didn't evolve anymore ;-) you sound like we did not have enough "change for the sake of change" in the past 6 years.. realize that the gain of changes needs to *really* outweight the costs all over the world and not just for you Well Reindle I was not expecting a positive reply but I need to pee as long as your are not able to distinct between firstname and lastname or at least quote the last name correctly: well, go pee, it's more productive than ideas change anything for no reason to bomb us (us is endusers and sysadmins) back some years (in fact after RHEL7 has systemd more than a decade) in context of consolidation for no gain Ooh, you set up a name switch bomb, very good of you. You must be Japanese, but not really. And the typing is just a typing error that I don't want to spend too much time on correcting these things while writing senselesse mails, you know. Ha, another one. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] thoughts on different command structure
Xen schreef op 05-10-2016 22:09: Reindl Harald schreef op 05-10-2016 21:50: as long as your are not able to distinct between firstname and lastname or at least quote the last name correctly: well, go pee, it's more productive than ideas change anything for no reason to bomb us (us is endusers and sysadmins) back some years (in fact after RHEL7 has systemd more than a decade) in context of consolidation for no gain Ooh, you set up a name switch bomb, very good of you. You must be Japanese, but not really. And the typing is just a typing error that I don't want to spend too much time on correcting these things while writing senselesse mails, you know. Ha, another one. I am not going to respond if you take it private. That's all. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
