[01:45] Eickmeyer: um, ok, so long as it runs after the ondemand one on ubuntu. [03:00] OvenWerks: It won't even run unless it's enabled, which it's not by default. [15:59] Eickmeyer: ok, Im confused. I am not sure "what" won't run unless its enabled" [16:01] OvenWerks: So, a systemd service file does nothing unless called upon. By sitting in /lib/systemd/system it does nothing unless someone calls "systemctl start *.service". Additionally, it does nothing at boot unless it's enabled by "systemctl enable *.service". [16:01] not true [16:02] at least that has not been my experience [16:02] Any systemd document I have ever read says what I wrote. [16:02] enable *.service just drops a link in the right place [16:03] The file simply "exists" until called upon. [16:03] if the link is pre installed it runs [16:03] Exactly, enabling it to be called-upon at boot. [16:03] In this case, I'm not doing that. [16:04] (not creating the link) [16:04] all of the scripts in /lib/systemd/ do nothing unless there is service that calls them. [16:05] From a package? [16:05] Correct, and that service must be in /lib/systemd/system and either A) linked in /etc/systemd/system or B) manually run. [16:05] a package should create all needed links [16:05] Are we still talking about -controls/ondemand? [16:05] That's correct, but if it's a systemd link it needs to be created the systemd way. [16:06] no that is not true. [16:06] Yes, but controls/ondemand is diferent. [16:06] the package can create the link just fine. [16:06] Ok, I'll rephrase that. A systemd link should be created the systemd way. [16:06] not for a package install [16:07] Which isn't hard (postinst: systemd enable foo.system) [16:07] *systemctl enable foo.system [16:07] I still disagree... but whatever. [16:08] the enable tends to put the links in /etc not in /lib/systemd/system/ [16:08] As it should. [16:08] Enable simply makes it run at boot. [16:08] the /etc/ should only be used for local config not package config [16:09] There are exceptions to that, in this case, systemd services. [16:09] that is so the system admin can modify the operation of the system without making package upgrade fail [16:09] Systemd throws that old rule out the window. [16:09] not very smart [16:10] not old rule but correct rule [16:10] But it is the way that it is. systemd is smarter at handling that situation than you think. [16:10] systemd also runs correctly puts in links in the correct places too. [16:11] Yes, but not unless it's told. [16:11] putting a link in the right place "tells" systemd what to do with it [16:12] That's correct. Such as when systemd is told to enable a .system file, it makes a link in /etc/systemd/system/{target.wants}. [16:13] It bases that link on the systemd file saying "WantedBy = *.target". [16:13] or even if the link is in /lib/systemd/system or a sub directory [16:13] I have tested this rather a lot [16:14] it does work even without use the "enable" command even with no link in /etc [16:14] Yes, but it doesn't automatically run in anything in /lib/systemd/system unless it's enabled. ondemand.service is an exception because it's enabled on Ubuntu systems already (there's a symlink in /etc/systemd/system/multi-user.target/) and it looks for anything in its directory called .conf. [16:15] There are rather a lot of commands/files in /lib/systemd/system and /lib/systemd/user that just run with no link what so ever in /etc [16:15] Yes, but the systemd file I made does not. It cannot unless it's "enabled". [16:15] wrong totallly wrong I have seen things run with out any enabling done [16:16] Then you have not put the link in the right place [16:16] Then those things have a link somewhere in /etc/systemd. [16:16] no they don't [16:16] No, I don't want the systemd file I made to run on Ubuntu. I only want it to run on Fedora. [16:17] Hence, I don't have Ubuntu enable it. [16:17] If it makes you feel better, I can have .postinst delete it during install. [16:17] unless systemd is totally different on fedora it likely works much the same way [16:18] so how many files are in /etc/systemd/system/*/ ? [16:18] Fine, I'll have postinst delete it, but it needs to be there for non-Ubuntu systems otherwise you can't even launch -controls. [16:19] wierd [16:19] it sounds like a really really bad design] [16:20] just like hard linking /lib/systemd to /usr/lib/systemd [16:20] Non-Ubuntu systems don't have ondemand.service. That's an ubuntu-only thing made to replace init.d/ondemand. So, nothing creates the cpufreq files that -controls reads when it starts. In order to fix that, I needed something to run a systemd service on boot. [16:21] That much I can see [16:23] And that is why I did what I did. I wouldn't want it to run at boot on Ubuntu since that conflicts with the operation of ondemand.service (not so much conflicts as runs the /systemd/ubuntustudio service twice). So, I made it "WantedBy=multi-user.target" so that it only gets called if it is seen in /etc/systemd/system/multi-user.target" as a symlink. [16:24] so create another *.service file in /lib/systemd/system/ called whatever.service. It should have in it: [16:24] [Unit] [16:24] Yes, that's exactly what this has. [16:24] Description=Set the CPU Frequency Scaling governor [16:24] ConditionVirtualization=no [16:24] ConditionPathExists=/sys/devices/system/cpu/online [16:25] [Service] [16:25] Type=idle [16:25] ExecStart=/lib/systemd/studio [16:25] It's much simpler than that: https://git.launchpad.net/ubuntustudio-controls/tree/lib/systemd/system/studio-system.service [16:25] That one does have an install segment [16:26] Yes, but that is for "systemctl enable" reference to make the symlink. The packaging file for rpms calls that as a postinst. [16:27] Otherwise it sits there and does nothing. I verified it already. [16:27] you can remove the Install section and just put a link in /lib/systemd/system/multi-user.target.wants/ too [16:28] but yes it could just be enabled [16:29] Exactly. Fedora (and openSUSE) like to do things the "systemd way" as opposed to Debian and Ubuntu that make a lot of compromises for people who objected to using systemd in the first place. [16:29] but looking at the system folder it looks like even ubuntu has put everyth8ing in /etc [16:30] Yep. That's done during the postinst scripts by way of "systemctl enable". [16:31] so, I guess we couold change all of the systemd stuff to do that. Its fine if not very "Linuxy" (or Unixy" [16:31] next question is does it work? [16:32] Yes, it works. [16:32] it may need ConditionPathExists=/sys/devices/system/cpu/online [16:33] It doesn't. [16:33] It just works the way it is. I have tested it. [16:33] maybe it is fixed then [16:34] Must be, but I do know I had to have kernel-tools installed since we change the cpu governor. [16:34] brb, kid to school. [16:35] when ubuntu first switched to systemd, and they were still using ondemand in /etc/init.d/ there were problems with it running too soon [16:35] in fact, so far as I know cpufreq still had that problem last I looked [16:36] (we don't use it anymore) [16:43] Eickmeyer[m]: it is probably ok to have both ways of running that installed. [16:43] it should not matter if it gets run twice (in ubuntu/debian) [16:45] or we could set up ubuntu so that ondemand is merely turned off and use the second method to actually do the work. [16:45] It sounds like in debian/buntu land, system is done one way and user another way. [16:46] it is also quite possible that debian/buntu basically ignores systemd in user land except for packages like pulse that come from and upstream that does systemd by default [16:48] (except for gnome which kind of messes things up) [16:52] I think that perhaps the debian packaging setup requires a multilevel config system for better stability when updating software... [16:53] And that's very possible. I think, for consistency sake, I'll have postinst remove the systemd service I created, but the packaging for Fedora keep it. [16:54] OvenWerks: For reference, here's the .spec file used to build the .rpm package: https://pagure.io/studio-controls/raw/master/f/studio-controls.spec [16:54] Eickmeyer[m]: The main thing in ubuntu is that ondemand has a delay in it (60 sec) [16:54] so it has to be "repaced" [16:54] In that, I remove the ondemand-service stuff. [16:55] *replaced [16:55] So, there's no reason why in Ubuntu I couldn't remove studio-system.service. [16:55] Just different ways of doing things. ¯\_(ツ)_/¯ [16:56] And, no, systemd isn't very unix-like. That was, and is, the biggest objection people have with it. [16:58] It would be nice to have one set of files that just works... but then it would not work with a system that still uses /etc/init.d for everything :P [16:59] There are somethings I like about systemd... [17:00] I think, at this point, we have a run-time dependency on systemd for -controls, tbh. [17:02] yup I don't think we nee to worry about making it work for slackware :) [17:03] Hahaha [17:03] Or Gentoo. [17:05] So, do we start working on unbranding it next cycle? [17:05] yes [17:05] Cool. [17:06] Either way, it runs and works on Fedora, haven't tried openSUSE yet. [17:08] Though, for Fedora, I did have to package python-jack and zita-ajbridge. [17:08] :) [17:08] they are both worth having anyway [17:09] Exactly. I was surprised they weren't there already. python-jack is undergoing review as we speak, and zita-ajbridge has been approved for release. [17:10] I'm waiting for those both to hit RawHide. Once those hit, submitting studio-controls will be the next step. [17:13] BTW, Fedora's default kernel (the only one they have, really) is very nicely optimized for lowlatency.