[06:16] Good morning === Osares102 is now known as Osares10 === cpaelzer_ is now known as cpaelzer === genii-core is now known as genii === vlm_ is now known as vlm === toabctl_ is now known as toabctl === akaWolf1 is now known as akaWolf === paulw2 is now known as PaulW2U === ^wuseman is now known as Guest3499 === lotuspsychje_ is now known as lotuspsychje === Beret- is now known as Beret === bahamat_ is now known as bahamat === kinghat4 is now known as kinghat === paulw2 is now known as PaulW2U === dbungert1 is now known as dbungert === JanC_ is now known as JanC [19:23] I am on Ubuntu Server 20.04 I have some docker-compose files that run on start up through systemd. When running in detached (`-d` or `--detached`) mode docker-compose immediately takes down the containers after they start, however this does not occur when not detached. Is it okay to run these service files without `-d`. I have not experienced any issues running multiple service files in this manner, but is there [19:23] problems that can occur? Thanks. [19:24] on my vm ubuntu server I currently use a @reboot crontab line to run my server automatically when i reboot the machine. Personally I don't have any experience starting custom systemd jobs, are there any reasons I should consider moving to systemd, such as, idk, something like being less taxing on the CPU, or is either way fine? [19:24] StoneMonarch: dunno docker but with systemd units, it's recommended to not detach [19:24] tar_xvf: reliability maybe? systemd can revive a dead process if you ask it to [19:25] @sdeziel much appreciated. [19:25] good point sdeziel , thanks [19:29] tar_xvf: getting output from the command in the journal etc might be convenient, rather than only ever getting failures emailed to you [19:29] i will look into that, thanks sarnold [19:29] tar_xvf: you can also set ulimits or seccomp restrictions or use systemd's namespace shenanigans to hide portions of the filesystem [19:31] tar_xvf: and the best reason I can think of is that if you want to restart the service for some reason, you'll get a consistent runtime environment to just systemctl stop the service, systemctl start the service, or systemctl restart, etc; to get the same execution environment a *second* time with cron would require adding a new cronjob entry to start the service, then go remove it again once it's [19:31] running [19:32] i like that reason. For me, usually i just restart the vm, but i have multiple services running on a machine so that would be good to restart one without disrupting the others too much. [19:38] my last question between the two, is running a script at startup via cron or systemd generally more CPU intensive, for the same script? or is that negligible [19:40] tar_xvf: it shouldn't matter [19:40] ok, thank you very much sarnold. [20:12] ummm... who's the apache2 expert? [20:13] because I think 18.04 upgrade has a broken Apache2 problem - if prefork is enabled it still tries to enable mpm_event and breaks PHP and such [20:13] and then triggers apt failures [20:16] blah i fixed it by manually overwriting the postinst >.> [20:17] I've seen do-release-upgrade disabling mod_php and leaving at that but that was fixed months ago... [20:29] sdeziel: it's possible then that was done, I think this is a 16.04 -> 18.04 upgrade bug because it's treating it as if it's a fresh install [20:29] and enabling mpm_event even if mpm_prefork is enabled, leading to a hard upgrade failure [20:29] i managed to *bypass* that for now, but... [20:29] it's something that took down a server today and is on my radar of "infinitely annoying things" === pizzaiolo is now known as pizza === genii is now known as genii-core