pbb has quit [Ping timeout: 272 seconds]
pbb has joined #nixos-systemd
hmpffff has quit [Ping timeout: 256 seconds]
hmpffff_ has joined #nixos-systemd
pbb has quit [Quit: No Ping reply in 180 seconds.]
pbb has joined #nixos-systemd
hmpffff_ has quit [Ping timeout: 272 seconds]
hmpffff has joined #nixos-systemd
hmpffff_ has joined #nixos-systemd
hmpffff has quit [Ping timeout: 256 seconds]
hmpffff has joined #nixos-systemd
hmpffff_ has quit [Ping timeout: 265 seconds]
hmpffff_ has joined #nixos-systemd
hmpffff has quit [Ping timeout: 256 seconds]
hmpffff has joined #nixos-systemd
hmpffff_ has quit [Ping timeout: 256 seconds]
hmpffff_ has joined #nixos-systemd
hmpffff has quit [Ping timeout: 265 seconds]
hmpffff has joined #nixos-systemd
hmpffff__ has joined #nixos-systemd
hmpffff_ has quit [Ping timeout: 265 seconds]
hmpffff has quit [Ping timeout: 246 seconds]
hmpffff__ has quit [Read error: Connection reset by peer]
hmpffff has joined #nixos-systemd
hmpffff_ has joined #nixos-systemd
hmpffff has quit [Ping timeout: 260 seconds]
hmpffff has joined #nixos-systemd
hmpffff_ has quit [Ping timeout: 240 seconds]
hmpffff_ has joined #nixos-systemd
hmpffff has quit [Ping timeout: 265 seconds]
balsoft has joined #nixos-systemd
infinisil has joined #nixos-systemd
emily has joined #nixos-systemd
<balsoft> Are there any logs for this?
<balsoft> Oh, samueldr has them. Sorry.
<balsoft> gchristensen: I think I've seen such issues before, but I don't remember how I fixed them :)
<flokli> balsoft mentioned in #nixos another usecase for units which are not directly part of the nixos system config, but another "mutable" profile on top - we currently have some terrible hacks in https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specific/linux/systemd/0005-Add-some-NixOS-specific-unit-directories.patch, but this basically is yet another example for "we want a mutable place to drop system
<flokli> unit files of some sort"
<balsoft> Oh, I see
<balsoft> I don't think this was part of my original question, but it's nice to know that there's this hack
<flokli> We could actually make /etc/systemd/system itself mutable again (but only contain "manually provided units"), and introduce another location for units "part of the NixOS system configuration"
<flokli> balsoft: please don't just use /etc/systemd-mutable lol
<flokli> this is currently Dysnomia private API of some sorts, and might be moved to a Dysnomia-specific thing
<balsoft> Nah, I'll just continue specifying a service in nixos configuration with `/nix/var/nix/profiles/my-app/bin/my-app` as `ExecStart` :)
<flokli> you might be able to have an activation script (or systemd generator) provisioning units in /run/systemd/system/…
<balsoft> Huh, interesting idea
<flokli> there has also been some discussion regarding reload behaviour - but I leave the log archaeology to you :-)
cransom has joined #nixos-systemd
<gchristensen> it is such a shame that there is no like, project-level systemd thing
<gchristensen> it would eat the lunch of foreman etc.
<flokli> gchristensen: there is. It's called portable systemd services
<gchristensen> mm?
<gchristensen> no, this is different I think
<flokli> so what are you looking for?
<andi-> gchristensen: you mean supervisord? ;-)
<andi-> much more involved then foreman but also more features
<gchristensen> I'm looking for a `foreman start` that I can apply to a nixos module
<gchristensen> inside a nix-shell
<flokli> huh
hmpffff has joined #nixos-systemd
hmpffff_ has quit [Ping timeout: 265 seconds]
<arianvp> TIL that systemd supports reading systemd units from a specific unit path
<arianvp> quite handy ;)
<arianvp> but not sure how we could change that env variable without re-execing :P
<arianvp> so maybe not so useful in nixos proper
<arianvp> oh wait wat
<arianvp> it's not just a unit path
<arianvp> but any amount of unit paths
<arianvp> so you can do
<arianvp> SYSTEMD_UNIT_PATH=our:custom:location:specific:nixos
<arianvp> without patching anything in systemd
<arianvp> flokli: !!
<arianvp> and it will read those paths in order; a la $PATH
<arianvp> trailing : means "in whatever paths you defined + the ones defined by system"
<flokli> jaja
<flokli> arianvp: how do they align with the rest of the paths baked into the binary?
<arianvp> this is just for units
<arianvp> all the others paths use the CONF_PATHS macro. unit paths are the exception
<flokli> yes, but does this totally replace the other unit paths?
<arianvp> yes
<arianvp> if you set
<arianvp> SYSTEMD_UNIT_PATH=/my/path then it replaces
<arianvp> if you have a trailing : it "adds"
<arianvp> SYSTEMD_UNIT_PATH=/my/path: adds
<arianvp> so that will expand to
<arianvp> SYSTEMD_UNIT_PATH=/my/path:/usr/lib/systemd:/etc/systemd:/etc/systemd.generator etc
<arianvp> documented in `man systemd` even :P
<arianvp> this means we can at least drop the unit path patch. neat
<arianvp> but yeh your custom path will always have presedence over the built-in ones
<arianvp> no control over that
<flokli> well, that should be ok to get rid of that one patch at least
<flokli> wanna file a PR?
<arianvp> yep
<arianvp> will do tomorrow
<flokli> <3
pbb has quit [Remote host closed the connection]