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